Preparing evidence for review and audit

Three requests in the same fortnight

A software services company in Hyderabad runs customer support and claims processing for an insurer. In the same two weeks it receives three requests. The insurer's vendor risk team sends a sixty question data protection questionnaire. The internal auditor wants to sample ten erasure requests from last quarter. And the managing director asks for a one page view of where the DPDP programme stands before the next board meeting.

The privacy lead has a shared drive folder called "DPDP evidence". It holds the privacy policy, the retention schedule, a request handling procedure and some screenshots. None of it answers what the auditor actually wants to know: for these ten requests, who verified the person, which systems were searched, what was erased, and when.

What the law expects you to be able to show

The DPDP Act and the DPDP Rules, 2025 put duties on every Data Fiduciary: answer the rights of Data Principals, erase data when the purpose is served, keep reasonable security safeguards, report breaches and bind processors by contract. Each of those duties carries a quieter second duty. If someone asks, you need to show you met it.

Some of that is written into the Rules directly. Rule 6 asks for logs and monitoring of access to personal data, and for those logs and the related personal data to be kept for at least a year so that incidents can be detected and investigated. A breach needs a detailed report to the Data Protection Board within 72 hours of becoming aware of it, and that report can only be as accurate as your records. A Significant Data Fiduciary has a yearly audit by an independent data auditor, who will test controls against records.

The DPDP Rules, 2025 were notified on 13 November 2025, and most of these duties apply from around 13 May 2027; check for later amendments. Evidence is the one area where you cannot catch up later. A record either exists from the day the work happened or it does not.

Who asks, and what they ask for

Four readers with different questions

Compliance evidence is requested by four kinds of reader, and each wants something different from the same underlying records. Knowing which reader you are preparing for changes what you assemble. A single general folder marked "compliance evidence" usually serves none of them well.

Management wants to know whether the programme is working. They look at counts and trends: how many obligations are open, how many have no owner, whether reviews happen on schedule, and how the position moves across a quarter.

An internal auditor picks a small sample and follows each case from start to finish, checking that what the process describes is what actually happened. They care whether the controls operate. A procedure that describes a control proves very little to them.

An enterprise customer or an independent auditor wants a description of your controls with real examples behind it, tested against a defined scope. The independent data auditor is a standing requirement for a company notified as a Significant Data Fiduciary. For an Indian IT or BPO firm serving regulated clients, the customer's reviewer shows up far more often than any regulator.

The Data Protection Board asks about one specific matter, usually after a complaint or a breach. When did the person contact you, what did you do, who handled it, what did you tell them, and why.

If you keep separate documents for each reader, you are maintaining four accounts of the same work and reconciling them under pressure. One set of operating records, viewed four ways, is easier and more reliable.

Why evidence cannot be written afterwards

The distinction that matters most is between a record made while the work was happening and a document describing the work later. They look similar, and they carry very different weight.

A record made at the time shows the date a request arrived, the date verification was completed, the date each system reported back and the date the response went out. Each timestamp came from the system that did the work. A document written a month later states the same sequence on the strength of somebody's memory.

Auditors and regulators test for the difference. When an auditor asks who verified a caller's identity and you answer from a record with a name and a time, the question ends there. If the answer is "probably the support team", it leads to more questions.

What good evidence actually contains

Decision records

Some of the most important evidence is about judgement. Why you chose a particular legal ground for a purpose. Why a retention period is set at seven years. Why part of an access response was withheld. Why an incident was judged reportable, or judged not reportable.

The reasoning fades quickly. Six months on, the outcome is visible in your systems and the thinking has gone. Write the reason down when the decision is made, against the thing it concerns, with the name of the person and the date. That record answers the hardest question an auditor asks, which is why you thought your action was right.

It also protects the people who made the decisions, who can show what information they had.

System action logs

Where work runs inside a connected system, such as an erasure in a CRM or a retention job in a data warehouse, the system's own log is the strongest proof you can offer. An erasure ran against these records in this system at this time and returned this result. A company that wants to show its retention rules actually run can point to execution records, which say far more than a schedule.

Keep the failures as well. An erasure that came back pending, an exception that stayed open for three weeks before someone fixed it, a verification that never came back. Those entries make the rest of the record believable. A log with only successes looks edited.

Review checklists

A periodic review leaves a checklist with a name and a date: the system owner confirmed what the system holds, the vendor owner reviewed the processor contract, the privacy lead checked a notice against the current inventory.

A good checklist also records what the reviewer looked at. "System reviewed" says little. A confirmation listing the data categories checked, the integrations examined and the person who signed it off can be tested. A company saying it reviews its inventory every year is making a claim. A company producing forty dated confirmations with names is producing evidence.

The gaps are informative too. Reviews that were due and missed should show up as missed, so you find them before anyone else does.

Putting a package together

Scoping what the reader needs

A package is defined by the question it has to answer, so start there and scope it.

• For a Board query about one person, gather everything about that person and that matter, in date order.
• For an internal audit of rights handling, give a sample of requests, each with its full sequence.
• For a management review, give the counts and trends, and the list of items with no owner.
• For a customer questionnaire, describe the controls and attach two or three real, redacted examples.

Scoping matters in both directions. A package that leaves out something relevant looks evasive. One that includes everything buries the answer.

What a good package looks like

A useful package has a short cover note saying what is included and why, followed by the records themselves, arranged so the reader can follow a case from beginning to end. For a rights request that means the request as received, the verification, the systems searched, the decisions taken, the action in each system with its outcome, and the response sent, in order and with dates.

Include the imperfect cases. If one request in the sample was answered late, show it with the record of how it was handled. Teams instinctively want to present only clean cases, and an auditor who selects the sample will find the others anyway. A package with a late response and an honest account of it reads well. A package with no rough edges at all reads as curated.

Management review

What leadership needs to see

Management review works at a different resolution from audit. Individual cases matter less than the shape of the programme, and the useful figures are few: how many obligations are open, how many have no owner, where unresolved exceptions are concentrated, whether scheduled reviews are being completed, how long rights requests take against the period you published, and how many incidents occurred and how they were handled.

Of those, the count of obligations with no owner usually carries the most weight with a board. A long unassigned list points to a basic problem, and the number makes the point without argument.

Reviewing the programme, and the paperwork second

A review that examines documents will usually conclude the programme is in good order, because the documents are usually fine. A review that examines the operating position finds the real state.

The useful questions are specific. Which obligations have been open longest, and why. Which systems are slowest to respond to actions. Where exceptions are piling up. Which reviews slipped this quarter and what caused it. Which decisions were taken with no reason recorded. A meeting that ends with a list of items and owners has done something. A meeting that ends with agreement that things look healthy has used up an hour.

Responding to the Board

What a regulatory question looks like

A question from the Data Protection Board usually follows a complaint or a breach you reported, and it asks about specific events. What happened to this person's data. When did they contact you. What did you do, and who handled it. What did you tell them, and when. Why did you reach that conclusion. What have you changed since.

Every one of those can be answered from operating records, and none of them can be answered from a policy. A company piecing the answer together from email archives and recollection is slow and incomplete, and it shows. The Board works as a digital office to its own timetable, and taking three weeks to answer a simple question about one person tells the regulator something about your record keeping that you never meant to say.

Being able to show a pattern

Some questions concern the programme as a whole. Do you generally answer requests within your stated period. Do your retention rules actually run. Are processors overseen.

Answering those needs evidence across many cases. A company that can show it answered a hundred requests within the period, with the dates, is answering with facts. That evidence only exists if it was kept consistently, including in the months when nothing seemed important. A regulator picking a quarter will not pick the one you were paying attention to.

What this position is worth

The same evidence has a commercial use that companies discover once they have it. Enterprise customers, particularly those governed by frameworks in other countries, check the data protection posture of their Indian suppliers as a condition of doing business. A company that can describe its controls and produce examples answers a questionnaire in days, where assembling it afresh takes a week per customer. For firms selling software, platforms or data handling services to regulated buyers, the commercial case usually lands before the regulatory one.

Where TrustOS fits

In TrustOS, evidence builds up as the work happens. Each obligation moves through requirement, responsibility, action and evidence, so decision records, system action logs and review checklists accumulate without a separate documentation effort.

You can assemble an evidence pack against a scope: a period, an obligation area, one Data Principal or one incident. The pack contains the underlying records, and packs can be verified cryptographically, so a reader can check that nothing was altered after export. Management figures, such as open obligations and unassigned items, come from the same records, so the quarterly report becomes a view you open, without a week of compiling.

TrustOS records what was done and when. The judgement on whether that satisfies the Act stays with your privacy and legal team.

Where to start

Evidence cannot be built after the fact, so it needs attention early, even though it produces nothing visible at first.

• Pick the area that draws the most attention, usually rights requests or breach response, and make sure every step leaves a dated record.
• Record the reason for each significant decision at the time it is made.
• Keep failed and pending actions in the log alongside the successes.
• Extend to the areas with periodic reviews, the inventory, notices and processors, and give each review a schedule and a named owner.
• Keep access logs for at least a year, as Rule 6 asks.
• Build each package from a defined scope, with a short cover note.

Do not wait for an audit date to start. Evidence written in the month before an auditor arrives is a description of past work, and that is exactly the material auditors discount. To see how records turn into a pack, look at the Evidence and audit module.