Vendor Compliance Checklist for DPDP Act, 2023 — A Banking Sector Guide

The DPDP Act strictly mandates that a Data Fiduciary may engage a Data Processor only under a "valid contract". This is non-negotiable. The Bank must obtain and validate: (a) A Valid Data Processing Agreement (DPA) — a signed, legally binding contract explicitly governing how the vendor processes the Bank's customer data, the categories of data involved, the permissible purposes, sub-processing restrictions, and termination obligations. (b) Mandatory Security Clauses — the contract must contain explicit provisions obligating the Data Processor to implement "reasonable security safeguards" commensurate with the sensitivity of the data. Vague language is legally insufficient. (c) Indemnity, Audit Rights, and Liability Frameworks — while the Act holds the Bank liable, standard compliance practice dictates that the DPA includes contractual indemnification from the vendor for breaches caused by vendor negligence, along with unilateral audit rights that allow the Bank to inspect vendor compliance at any time without prior notice restrictions. Without these artifacts, the Bank has no legal or contractual recourse if the vendor causes a data breach that results in regulatory penalty.

The Bank must obtain documented technical evidence — not just vendor representations — that the following security safeguards are operational: (a) Encryption and Masking Policies: Artifacts proving the vendor implements data security measures including encryption at rest and in transit, data obfuscation, masking of sensitive fields (such as Aadhaar numbers, account IDs, or transaction amounts), and the use of virtual tokens mapped to personal data. (b) Access Control Matrices: Formal documentation of Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) frameworks restricting which personnel and systems can access the Bank's data within the vendor's environment. (c) Technical and Organisational Measures (TOMs): Third-party audit reports, ISO/IEC 27001 (Information Security) or ISO/IEC 27701 (Privacy Information Management) certifications, or SOC 2 Type II reports that independently validate the vendor's security posture. Self-attestations are not sufficient. (d) Business Continuity and Data Backup Plans: Written policies with RPO (Recovery Point Objective) and RTO (Recovery Time Objective) commitments, outlining how the vendor will ensure continued processing and data recovery if the confidentiality, integrity, or availability of the Bank's data is compromised by a disaster, cyberattack, or infrastructure failure.

Rule 8(3) of the DPDP Rules creates one of the most technically specific compliance obligations in the Act. The Bank must ensure that the Data Processor retains personal data, associated traffic data, and all logs of the processing activity for a minimum period of one year from the date of processing — specifically to enable the detection and forensic investigation of unauthorized access events. Rule 8(3) uses the explicit illustration of a "cloud service provider" as the Data Processor, making clear that this obligation is squarely aimed at the Bank's cloud vendors, SaaS platforms, and managed service providers. The Bank must obtain: (a) A written Log Retention Policy from the vendor confirming 1-year minimum retention with tamper-evident log storage. (b) Technical Architecture Documents showing how logs are stored, in what format, with what access controls, and how they can be extracted for forensic investigation or regulatory production. (c) Cloud Hosting Retention Proof: If the vendor uses sub-processors for cloud storage (e.g., AWS, Azure, GCP), the Bank must confirm that the log retention chain flows through to those sub-processors and that no logs are auto-deleted before the mandatory one-year period expires. This is non-trivially enforced in practice — most cloud providers have default log rotation policies of 30–90 days. The Bank must ensure these defaults are overridden contractually and technically.

The Bank is legally mandated to notify the Data Protection Board (DPB) of any personal data breach within 72 hours of becoming aware of it — including detailed forensic facts about the nature, extent, timing, and location of the breach, as well as remedial measures taken. This 72-hour clock is absolute. If a vendor breach occurs on Day 1 and the vendor notifies the Bank only on Day 3, the Bank's 72-hour window has effectively been consumed by vendor notification delay. To prevent this, the Bank must obtain: (a) Breach Notification SLAs: A contractually binding Service Level Agreement with the vendor guaranteeing notification to the Bank within 12–24 hours of the vendor discovering or suspecting a data breach — not after internal vendor investigation is complete. (b) Incident Investigation Workflows: Documented incident response runbooks showing how the vendor will provide the Bank with: the broad facts and timeline of the breach event; the nature and scope of personal data affected; the location and root cause of the breach; the containment and remedial measures taken or planned. Without this structured information, the Bank cannot populate its mandatory DPB notification with the required forensic detail — making the Bank non-compliant even if it files within 72 hours.

The DPDP Act creates active obligations around the entire data lifecycle — not just collection and processing. The Bank must validate three critical vendor capabilities: (a) Data Erasure Workflows and Destruction Certificates: The Bank is legally required to cause its Data Processor to erase any personal data when the specified purpose is no longer being served (i.e., purpose limitation) or when the data subject withdraws consent. The Bank must validate the vendor's automated data deletion pipelines and require formal Certificates of Destruction as auditable evidence for each erasure event. Manual deletion logs or verbal assurances are not acceptable. (b) Data Correction Syncing Mechanisms: When a customer exercises their right to correction or updation of inaccurate or misleading data, the Bank must ensure that correction propagates downstream to every vendor that holds a copy of that data. The Bank must verify that the vendor has APIs, webhooks, or operational protocols to immediately process data correction instructions from the Bank without delay. (c) Vendor Identity Documentation: Data Principals have a statutory right under the DPDP Act to request a summary of their personal data and identities of all Data Processors with whom their data has been shared. The Bank must therefore maintain verified corporate identity records (CIN, registered address, key personnel) for every active vendor — so it can produce this information to customers upon demand.

If the vendor processes, stores, replicates, or routes the Bank's customer data outside India — even transiently, as in the case of CDN caching or disaster recovery replication — the Bank faces additional obligations under the DPDP Act. The Central Government retains the power to issue general or special orders restricting the transfer of personal data to specific foreign states or territories. The Bank must obtain: (a) Data Flow and Residency Maps: Architectural and network flow diagrams showing where the Bank's data resides, where it transits, in which jurisdictions it is processed, and which sub-processors have access to it across borders. (b) Restrictive Transfer Compliance Confirmation: A vendor certification that their infrastructure does not route or store the Bank's data in any jurisdiction that is or may be restricted by the Central Government. This must be actively monitored — not just confirmed at onboarding — since government restriction orders may be issued at any time. (c) Sub-Processor Chain Documentation: If the vendor uses a global cloud provider with multi-region architecture, the Bank must trace the full sub-processor chain and confirm data residency at each node.

The following is the definitive list of documents and evidence the Bank must formally obtain, review, and retain in its vendor compliance register: 1. Valid Contract (Data Processing Agreement): A formal, legally binding contract under which the vendor is engaged to process personal data on the Bank's behalf. 2. Contractual Security Safeguard Provisions: Specific, explicit clauses within the contract requiring the vendor to implement "reasonable security safeguards" — not generic boilerplate. 3. Evidence of Technical Security Measures: Documentation proving the vendor secures personal data through encryption, obfuscation, data masking, or virtualized token mapping. 4. Access Control Documentation: Evidence of the vendor's Role-Based Access Control or equivalent framework strictly governing access to the Bank's data. 5. Data Backup and Continuity Plans: Written plans with RPO/RTO commitments proving the vendor can recover the Bank's data in the event of a compromise to data availability or integrity. 6. One-Year Log Retention Proof: Architecture documents or technical evidence confirming all processing logs and traffic data are retained for a minimum of one year — commensurate with Rule 8(3). 7. Incident Management and Breach Notification Protocols: Documented SLAs guaranteeing the vendor will immediately provide detailed forensic facts to the Bank within 12–24 hours of any breach — enabling the Bank to meet its 72-hour DPB notification deadline. 8. Data Erasure Confirmations and Destruction Certificates: Formal, auditable proof that the vendor successfully deletes all personal data upon Bank instruction, with signed certificates of destruction for each erasure event.