DPDP Act checklist for fintech engineering teams

Most fintech DPDP programmes start with the consent banner. The bigger exposure usually sits on the laptops of the people who touch customer data every day.

Think about where a customer’s PAN, KYC record or bank statement actually ends up. A support engineer exports a CSV to debug a failed payout. A developer pulls a slice of the production database to reproduce a reconciliation bug. An analyst keeps last quarter’s loan book in a spreadsheet in Downloads. A Postman collection still holds a live customer token.

None of this is malicious, and all of it is personal data under the Act. Once it lands on an endpoint, it falls outside most of the controls you built for production.

I saw this first-hand while working on observability for public-sector banks. Core banking logs carried personal and financial records, and employees could download them with a click. That experience is why we started Scanyx, and it shapes this checklist.

This post is written for engineering leaders, not lawyers. For each item: what to check on the endpoint, which DPDP Rule it maps to, and what evidence to keep.

Where the deadlines stand (November 2026)

The security, breach-reporting and retention duties bite on 13 May 2027, six months from now. 13 November 2026 is not a general deadline, despite what some LinkedIn posts suggest.

The stakes are set in the Act’s schedule: up to ₹250 crore for failing to take reasonable security safeguards, and up to ₹200 crore for failing to notify a breach.

In January 2026, MeitY floated cutting the 18-month runway to 12 months. As of early November 2026, no amendment to Rule 1 has been found in the Gazette, so May 2027 still stands. Watch for it anyway: a notified change would pull the date forward with little notice.

Two other clocks already run for most fintechs. CERT-In expects cyber incidents reported within six hours of discovery, far tighter than DPDP’s 72. And if you are a payment aggregator or PPI issuer, the new RBI directions are already in force.

Why laptops are the blind spot

Rule 6 requires reasonable security safeguards for personal data in your possession or under your control. It makes no exception for copies on an employee’s machine.

Most fintechs have solid controls in production: private networks, IAM, encrypted databases, audit trails. The moment a record is exported, it lands where none of those controls reach.

Every arrow on the left is a routine part of someone’s job. Every arrow on the right is how a routine export turns into a breach notification.

The checklist: 10 checks for data on laptops

Each check names the Rule it serves and the evidence to keep. Evidence matters most: after May 2027, “we had a policy” will count for less than a report that shows the control worked.

1. Know what personal data sits on each endpoint

Maps to: Rule 6(1)(c) visibility, Rule 7 breach particulars

You cannot describe a breach’s nature and extent within 72 hours if you don’t know what was on the lost laptop.

• Check: scan Downloads, Desktop, repos, log folders and DB clients for PAN, Aadhaar numbers, bank account and IFSC pairs, card numbers, KYC images and statements. Include .csv, .xlsx, .sql, .json, .har and .env files.
• Evidence: a per-device inventory with counts by data type, refreshed at least weekly.

2. Keep production data off laptops by default

Maps to: Rule 6(1)(a) security measures, Rule 6(1)(d) continuity

The cheapest laptop control is data that never arrives.

• Check: dev and staging use masked or synthetic data. Production access goes through a bastion or query tool that limits bulk export. No production dump lives only on a laptop.
• Evidence: a written data-handling standard, and an exceptions log with a ticket, owner and expiry date for each.

3. Encrypt the disk; mask and tokenise what must be there

Maps to: Rule 6(1)(a), which names encryption, obfuscation, masking and virtual tokens

• Check: full-disk encryption (FileVault, BitLocker, LUKS) enforced through MDM, with keys escrowed. Exports show masked PAN and tokenised account numbers unless a person truly needs the full value.
• Evidence: an MDM compliance report showing encryption status for every device, including contractors’.

4. Control who can pull data onto a laptop

Maps to: Rule 6(1)(b) access control

• Check: export rights in admin panels, BI tools and database clients follow least privilege. SSO and MFA everywhere. Offboarding revokes access and wipes the device on the last day.
• Evidence: quarterly access reviews and offboarding records.

5. Log access and keep the logs for a year

Maps to: Rule 6(1)(c) logs and monitoring, Rule 6(1)(e) and Rule 8(3) one-year retention

• Check: log who exported what, from which system, to which device. Capture file events for sensitive files on endpoints. Store logs where the user cannot edit them, for at least one year.
• Evidence: retention settings, plus one worked trace from export to device you can show an auditor.

6. Rehearse the lost-laptop breach

Maps to: Rule 7 breach intimation

Get Saurabh’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The Rules set a two-step clock: an initial intimation to the Data Protection Board without delay, then detailed particulars within 72 hours. Affected customers must also be told without delay, and CERT-In expects a report within six hours.

• Check: a runbook that starts from “a laptop was stolen from a cab” and answers three questions fast: was it encrypted, what personal data was on it, and whose.
• Evidence: the runbook, a tabletop exercise record and a current contact list.

DPDP has no materiality threshold for reporting. Whether a lost, encrypted laptop counts as a breach turns on whether confidentiality was actually compromised, so the proof from checks 1 and 3 is what lets you answer with confidence. Agree the position with counsel before you need it.

7. Erase local copies when the purpose is served

Maps to: Rule 8 retention and erasure

Erasure that stops at the database misses the copies in someone’s Downloads folder.

• Check: a retention period for local exports, with stale files flagged or removed automatically. Erasure requests reach endpoint copies, not just systems of record.
• Evidence: a retention policy that names endpoints, and deletion reports.

Rule 8(3) also requires keeping personal data and processing logs for at least a year. Meet that in controlled systems, not in stray laptop copies, and confirm the split with counsel.

8. Bring contractors, vendors and outsourced teams into scope

Maps to: Rule 6(1)(f) processor contracts

• Check: contracts with processors, collection agencies, BPOs and support vendors require reasonable security safeguards. Their staff’s devices are managed, or they work through VDI.
• Evidence: signed clauses and device attestations from each vendor.

9. Watch what leaves through AI tools and agents

Maps to: Rule 6(1)(a) to (c)

The newest exit path is a prompt. An engineer pastes a KYC record into a chatbot to fix a parser, or a coding agent with shell access reads an .env file.

• Check: an inventory of AI assistants and agents running on laptops, an approved-tools list, and redaction or blocking of personal data sent to unapproved tools.
• Evidence: the approved-tools list and the alerts raised against it.

10. Name an owner and train the people who handle exports

Maps to: Rule 6(1)(g) technical and organisational measures

• Check: one named owner for endpoint data risk. Short, specific training for support, risk, collections and engineering on where exports may live and for how long.
• Evidence: training completion records and an owner listed in your DPDP register.

Where to start: the next 90 days

Six months is enough if the first month goes on finding out, not writing policy. A sequence that works for a 50 to 500 person fintech:

1. Days 1 to 30: measure. Scan every laptop for personal data (check 1) and pull the MDM encryption report (check 3). The two numbers you want: how many devices hold customer data, and how many of those are unencrypted.
2. Days 31 to 60: shrink. Clean up the worst devices first. Move dev and staging to masked data (check 2), tighten export rights (check 4) and set a retention period for local exports (check 7).
3. Days 61 to 90: prove. Turn on export and file logging with one-year retention (check 5). Run the lost-laptop tabletop (check 6) and get vendor attestations (check 8).

Checks 9 and 10 run alongside all three phases. By February 2027 you should have three months of evidence before the deadline, not a slide that says “in progress”.

How Scanyx helps

We built Scanyx for exactly checks 1, 7 and 9. A lightweight agent on each laptop finds PAN, Aadhaar, account numbers and other personal data at rest. It shows which devices hold what, and flags data leaving through uploads and AI tools. Findings reach your team masked, so the tool doesn’t become another copy of the data.

It is free for up to 5 laptops. If you run engineering or security at a fintech and want to see your own numbers before May 2027, write to saurabh@scanyx.io for a demo.

This post is an engineering view of the DPDP Rules, not legal advice. Confirm how each obligation applies to you with your counsel.

Sources

• Data Fiduciary obligations under the DPDP Rules, 2025 (TaxGuru): Rules 6, 7 and 8
• 13 November 2026 under the DPDP Act: what starts and what doesn’t (The Privacy Labs)
• MeitY plans to cut short DPDP compliance timeline (S.S. Rana & Co.)
• DPDP deadlines: what happens in 2026 vs 2027 (India AI Rulebook)
• Operational impacts of India’s DPDPA: data breaches (IAPP): penalties and the CERT-In six-hour window
• RBI cyber resilience Master Directions for non-bank PSOs, 5 November 2026 (FinTech BizNews)