A data platform cannot certify itself: building an evidence pack for India privacy review

A data inventory, an encryption setting, and a deletion job can all exist while reviewers still cannot answer a basic question: what personal data moves through this workflow, under whose approved instruction, to which recipients, for how long, and with what evidence when something changes? A platform diagram may list products yet omit copied extracts, retries, support access, analytics events, model prompts, backups, exports, and manual work queues. The missing detail is where privacy review becomes guesswork.

The engineering objective should be narrower and more useful than a compliance claim. Build a versioned record that lets the customer’s qualified legal, privacy, security, sector, records, procurement, and operational reviewers inspect data movement, approved policy inputs, implemented behavior, exceptions, and ownership. Technology can enforce a configured rule and show what happened. It cannot decide whether the rule is legally sufficient, which provisions apply, when they apply, or whether the organization should accept the remaining risk.

The official India Code record for the Digital Personal Data Protection Act, 2023 is the primary location used in this draft. When checked, the record displayed the Act together with Rules, a corrigendum, and related notifications. Their presence is a reason to send applicability, timing, interpretation, and implementation questions to qualified counsel—not a basis for this article to summarize obligations. The NeGD National Data Governance page and API Setu page provide separate public context for governed data and interoperable interfaces. Neither determines personal-data legal conclusions or grants access to a government system.

Define the review object before selecting controls

“Data platform” is too large a unit for an accountable decision. Choose one bounded workflow and identify its start and end: a customer submits information, an employee opens a case, a sensor creates an event, an analyst produces a segment, an AI assistant retrieves records, or a vendor receives an export. Include the user interface, APIs, queues, stores, transformations, dashboards, support tools, backups, and manual steps that participate in that flow.

Give the review object a stable identifier and version. Record the business owner, technical owner, data owner, review owners, environments, release identifier, and linked decision records. State what is outside the boundary. If an upstream system supplies a classification or an external processor handles a file, link to the responsible review rather than leaving an unlabeled arrow.

The boundary should be reproducible from configuration and runtime evidence. An architecture workshop drawing that cannot be reconciled with deployed interfaces, storage resources, scheduled jobs, and vendor flows is a hypothesis. The review pack should show how the team checked it and list unresolved discovery gaps.

Build a data-flow register that includes inconvenient copies

For every source, derived record, message, file, cache, search index, feature, prompt, response, log, and export in scope, record fields that reviewers can interrogate:

Do not stop at primary databases. Include object-storage versions, dead-letter queues, observability payloads, email attachments, exported spreadsheets, local support downloads, data-science notebooks, feature stores, vector indexes, temporary extraction directories, recovery copies, and vendor consoles where they exist. The goal is not an endlessly expanding document; it is a controlled method for discovering copies and assigning owners to gaps.

Avoid placing real personal records in the register. Schemas, classifications, lineage identifiers, configuration references, and approved synthetic examples are usually safer review material. If reviewers need record-level evidence, access and retention for that evidence should be separately approved.

Keep policy decisions as external, versioned inputs

Purpose, notice, consent, lawful use, retention, deletion exceptions, rights handling, children’s data, transfer, and breach decisions are not constants that engineers should infer from an Act title or a generic checklist. Capture each applicable customer-approved instruction as a versioned input with its decision owner, source record, effective date supplied by the customer, affected workflow, and review trigger. Engineering tickets and configuration should reference that identifier.

This separation has practical value. A retention service can execute a duration and trigger, but it should not invent either. An access-policy engine can evaluate attributes, but it cannot choose who ought to qualify. A workflow can record a notice version or consent event when instructed, but the team should not describe that mechanism as proof that the notice, consent, or legal basis is sufficient. A data catalog can store purpose metadata, yet a populated field does not establish legal validity.

When an instruction changes, the team needs an impact query: which stores, interfaces, jobs, vendors, models, dashboards, backups, and open requests depend on the old version? Record the migration and exceptions. Silent edits to a policy spreadsheet are not an operating control.

Implement controls that produce verifiable behavior

Controls should have a testable statement, a mechanism, an owner, evidence, a failure signal, and an exception route. “Access is restricted” is not testable. “The service identity for workflow X can read fields A and B from interface version Y; denied fields produce an auditable authorization event; quarterly review is owned by role Z” gives reviewers something to inspect and challenge.

For access and minimization, show field- and operation-level permissions where the architecture supports them, privileged paths, role or attribute mapping, service-account ownership, unused-field removal, denied-path tests, and review history. Do not claim that minimization is achieved merely because a view contains fewer columns; reviewers need to understand upstream copies, downstream joins, free-text fields, and alternate interfaces.

For lifecycle behavior, test the customer-configured trigger from end to end. Create approved synthetic data, allow it to propagate to relevant stores and indexes, invoke expiration or deletion, verify each in-scope copy, record exceptions such as approved holds, and check whether a restore or replay can reintroduce the record. Deletion logs alone are weak evidence if they do not identify the object, policy version, affected locations, outcome, and failed retries.

For quality and lineage, connect a reported value back to source, transformation, code version, and exception history. Incorrect linkage can expose another person’s record or route a request to the wrong subject even when encryption and access systems operate normally. Quality controls belong in the privacy evidence pack when their failure changes identity, scope, recipient, or action.

Treat rights-related workflows as support mechanisms

Engineering can provide intake, identity-verification hooks, search, case routing, export, correction, restriction, deletion actions, status tracking, and response evidence under customer-approved rules. This article does not determine which rights exist for a person, when a request is valid, what exceptions apply, how identity should be established, or which response is legally sufficient.

Model the workflow as states rather than a single “delete user” endpoint: received, identity step required, scope under review, systems discovered, owner actions pending, exception referred, quality checked, approved response sent, and evidence closed. Each state needs authorized roles, time stamps, decision references, and an escalation path. Search results should identify confidence and unresolved systems instead of pretending discovery is complete.

Test with synthetic cases that cross systems. Include conflicting identifiers, a record present only in a backup index, a vendor export, a failed downstream action, an approved exception, and a correction that must propagate to analytics or AI indexes. The evidence should distinguish an engineering failure from a decision awaiting a qualified reviewer.

Map vendors and APIs as data relationships, not logos

For each external or internal interface, record the sending and receiving owners, data fields, direction, purpose instruction, authorization, schema version, error and retry behavior, logging, retention behavior, and contract or review reference supplied by the customer. The API Setu page is useful public context for interoperability, but it does not authorize a particular API or data exchange.

Retries deserve special attention. A timed-out request may have succeeded remotely, creating duplicate records or repeated disclosures when retried without idempotency. Dead-letter queues may retain full payloads longer than the primary workflow. Diagnostic logs can capture tokens, identifiers, or document text. Contract tests should cover unauthorized fields, schema drift, partial failure, duplicate requests, revoked credentials, and vendor unavailability.

Maintain a route for vendor and interface changes. Adding a field, destination, subprocessor, model endpoint, support-access path, or logging sink should trigger impact review before release when the customer’s process requires it. Inventory automation can detect resources and traffic, but a person still owns classification and acceptance.

Preserve incident and change evidence without writing a narrative after the fact

An incident record should connect detection, affected workflow version, data categories supplied by the customer, systems, time range, access or transmission events, containment, recovery, evidence preservation, decision owners, and follow-up controls. Legal or regulatory notification conclusions remain with qualified reviewers. Engineering should provide reliable facts and avoid turning preliminary estimates into definitive statements.

Design logs for investigation before an incident occurs. Use stable correlation identifiers, synchronized time, configuration versions, authorization outcomes, administrative actions, data-job runs, deletion failures, and export events. Restrict and retain those logs under approved instructions; an unrestricted audit store can become another sensitive data set.

Changes need similar discipline. A pull request can show code review but not the entire data effect. Attach schema changes, configuration differences, data migration behavior, backfill or replay scope, vendor changes, test evidence, approvals, deployment result, exceptions, and rollback status to the review object. Schedule re-review on material changes rather than treating a launch decision as permanent.

Assemble evidence for an actual approve, condition, or reject decision

A useful review packet is concise at the top and traceable underneath. Its decision summary should identify the workflow version, scope, owners, customer policy inputs, unresolved gaps, material changes, test results, and requested outcome. Supporting records can live in controlled systems, but links and versions must survive staff changes and later investigation.

Before release, reviewers should be able to locate:

• a current boundary and data-flow register reconciled with deployed systems;
• the customer-approved classification and policy-input references used by the implementation;
• access, minimization, lifecycle, quality, and lineage configurations with representative tests;
• rights-workflow hooks and synthetic end-to-end results, including exceptions and failed actions;
• vendor and API field maps, authorization paths, retries, logging, and change records;
• incident signals, evidence-preservation method, operational owners, and escalation contacts;
• known gaps, compensating actions, expiry dates, and the person authorized to accept each condition;
• rollback or disablement steps and the event that triggers renewed review.

The output is not a badge. It is a recorded decision for one bounded version: approved, approved with conditions, or rejected, with rationale supplied by the responsible reviewers. If the system changes, the evidence changes. If the customer’s instructions or legal interpretation change, engineering must identify affected controls and return the workflow to review.

That discipline is the practical meaning of “DPDP-aware” in this architecture: the platform does not claim to settle the law. It makes its data movement, configured behavior, failures, exceptions, and ownership visible enough for qualified people to make and revisit a decision.