Preparing Evidence for Review and Audit

Compliance evidence gets requested by four kinds of reader, and each of them wants something different from the same underlying records.

Knowing which reader you are preparing for changes what you assemble, and companies that keep one general folder marked compliance evidence usually find it serves none of them well.

Management wants to know whether the programme is working. They are looking at counts and trends, at where ownership is missing, at whether reviews are happening on schedule and at how the position is moving across a quarter.

An internal auditor wants to test a sample. They select a handful of cases and follow each one from beginning to end, checking that what the process describes is what actually happened. Their interest lies in whether the controls operate and not in whether they exist on paper.

An independent auditor, and that is a standing requirement for companies notified as Significant Data Fiduciaries, does something similar with more formality and against a defined scope. And the Data Protection Board asks about specific events, usually following a complaint or a breach, and wants to know what the company did and when.

One set of operating records serves all four readers. A company holding separate documentation for each reader is maintaining four accounts of the same activity and reconciling them under pressure.

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

A contemporaneous record shows the date a request arrived, the date verification was completed, the date each system reported, and the date the response went out. Each of those timestamps came from the system that did the work, while a document written afterwards states the same sequence on the authority of somebody memory.

Auditors and regulators know the difference, and they test for it. Asking who verified a particular identity, and receiving an answer from a record with a name and a time, ends the question. Receiving an answer that somebody believes it was probably handled by the support team invites more questions.

TrustOS produces evidence as a consequence of the work and not as a separate exercise. Decision records, system action logs and review checklists accumulate as the obligations are met, and preparing a package means gathering what already exists.

Some of the most important evidence concerns judgements and not activity. Why a particular processing ground was chosen for a purpose. Why a retention period was set at that length. Why material was withheld from an access response. Why an incident was assessed as reportable or not.

Each of those decisions was made by a person applying the Act to the company circumstances, and the reasoning behind it fades quickly. Six months later the outcome is visible in the systems and the thinking has gone.

TrustOS records the decision against the thing it concerns, with the reasoning, the person who made it and the date. That record answers the most difficult question an auditor asks, and it concerns why you thought your action was right.

It also protects the individuals who made the decisions. Somebody who reached a defensible conclusion on the information available has a record showing what that information was, and that position is far stronger than defending a decision from memory.

Where the platform executes work inside connected systems, the execution leaves a log. An erasure ran against these records in this system at this time and returned this result. A retention action completed here and returned pending verification there.

That log is the strongest form of evidence available, since the system that performed the work produced it instead of a person reporting on it. A company demonstrating that its retention rules actually run can point at execution records instead of a schedule.

The logs also record what did not happen, and that matters as much. An action that failed, an exception that stayed open for three weeks, a verification that never came back. A record showing only successes describes a system nobody would believe.

Periodic reviews produce their own evidence, and it takes the form of a completed checklist with a name and a date against it. The system owner confirmed what their system holds. The relationship owner reviewed the processor contract. The privacy lead checked the notice against the current data inventory.

A checklist also captures what the reviewer looked at, and that detail carries weight later. A confirmation stating that a system was reviewed says little. A confirmation listing the data categories checked, the integrations examined and the owner who signed it off can be tested.

Those confirmations turn a general claim into a set of specific facts. A company stating that it reviews its inventory annually is making an assertion. A company producing forty confirmations with dates and names is producing evidence.

The gaps are equally informative. Reviews that were due and not completed appear as such, and a company that knows where those gaps are can address them before anybody else finds them.

An evidence package is defined by what it has to answer. A request from the Board following a complaint needs everything about that individual and that matter. An internal audit of rights handling needs a sample of requests with their full sequences. A management review needs the counts and the trends. An enterprise customer security review needs a description of controls with examples.

TrustOS allows a package to be assembled against a scope, whether that is a period, an obligation area, an individual or a specific incident. What comes out is the underlying records and not a summary written about them.

Scoping properly matters in both directions. A package that omits something relevant looks evasive when the omission is noticed. A package that includes everything available buries the answer and makes the reader work, and that is its own kind of failure.

A useful package has a short covering description of what is included and why, then the records themselves organised so the reader can follow a case from beginning to end.

Auditors follow a case end to end, so the package should support that. For a rights request that means the request as received, the verification, the systems searched, the decisions taken, the actions in each system with their outcomes, and the response sent, in sequence with dates.

Where something went wrong, the package includes that. An exception that stayed open, a response sent late, an action that failed. Companies instinctively want to present only clean cases, and an auditor selecting the sample will find the others anyway. A package that includes a late response alongside the record of how it was handled reads well. One that appears to contain no imperfect cases at all does not.

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 are taking against the published period. How many incidents occurred and how they were handled.

Among those, the count of obligations with no owner tends to carry the most weight with a board. A programme where everything has a named owner has a question about performance in front of it. A programme with a long unassigned list has a more basic problem, and the number states it without argument.

TrustOS produces those figures from the operating records, so a management report becomes a view instead of an assembly exercise. Companies producing that report by hand each quarter know how much of the quarter it takes.

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

The questions worth asking are specific. Which obligations have been open longest and why. Which systems consistently take longest to respond to actions. Where are exceptions accumulating. Which reviews slipped this quarter and what caused it. Which decisions were taken without reasoning recorded.

Those questions produce work instead of reassurance, and that is the point of a review. A meeting that ends with a list of items and owners has done something. A meeting that ends with an agreement that the programme looks healthy has consumed an hour.

A question from the Data Protection Board usually follows a complaint from an individual or a breach the company reported. It concerns a specific matter and it asks about specific events.

What happened to this person data. When did they contact you. What did you do. 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 is answerable from operating records and none of them is answerable from a policy. A company assembling the answer from message archives and recollection is slow, incomplete and visibly so.

Speed matters in these exchanges more than companies expect. The Board operates digitally and works to its own timetable, and a company taking three weeks to answer a straightforward question about one individual has told the regulator something about its record keeping without meaning to.

TrustOS holds the sequence for each matter, so the response is drawn from the record. Where the company handled something badly, the record shows that too, and knowing it before responding is far more comfortable than discovering it in correspondence.

Some regulatory questions concern the programme instead of one case. Whether the company handles requests within its stated period generally. Whether its retention rules actually operate. Whether processors are overseen.

Answering those requires evidence across many cases, and that is where the accumulated records matter more than any single one. A company able to show that it answered a hundred requests within the period, with the dates, is answering a question about its programme with facts.

That evidence is only available to a company that kept it consistently, including for the periods when nothing seemed important. A regulator selecting a quarter does not choose the quarter the company was paying attention.

The same evidence serves a commercial purpose that companies discover once they have it. Enterprise customers, particularly those governed by other frameworks, examine the data protection posture of their Indian suppliers as a condition of doing business.

Those reviews arrive as security questionnaires, contractual requirements and sometimes audits. A company able to describe its controls and produce examples answers them in days. A company assembling the answer for each customer separately spends a week per review and grows less accurate each time.

For companies selling software services, platforms or data handling capabilities to regulated buyers, this reader arrives more often than any regulator, and the commercial case for the evidence usually lands before the compliance one.

Evidence cannot be built retrospectively, so it deserves attention early even though it produces nothing visible at first. The records only exist if the work was recorded as it happened.

A reasonable starting point is to pick the obligation area carrying the most regulatory attention, usually rights requests or breach response, and make sure every step of it leaves a record. From there, extend to the areas where reviews are periodic, which are the inventory, notices and processors.

What companies should avoid is treating evidence as a project to run before an audit. Preparing evidence in the four weeks before an auditor arrives means writing descriptions of past work, and that is precisely the kind of material an auditor discounts.

TrustOS is a DPDPA compliance platform developed and operated by Code Colonies Private Limited. It gives privacy, legal, security, technology, operations and audit teams a single system for personal data records, purposes and notices, consent and withdrawal, requests and grievances from individuals, retention and erasure, breach response, processor oversight and compliance evidence. Every obligation is connected to a responsible owner, turned into assigned work, tracked through to completion, and left with the records that an audit or a regulatory response will call for.

The platform can be deployed inside infrastructure that you control, and the agreed scope can include source code handover, environment setup, security configuration, technical documentation, integration support and knowledge transfer. A scoped gap assessment establishes your current position, the responsible teams, the priority gaps, the technical dependencies and a practical order in which to implement.

To see the platform or to discuss your requirements, continue to the product overview or start a gap assessment. To learn more about our consulting and engineering work, visit codecolonies.com. To start a conversation, write to us at consulting@codecolonies.com.