Passport scans leaked: your DPDP breach response

A staff laptop with 400 client passport scans goes missing from the back seat of an auto. A shared Google Drive link with three years of visa applications gets forwarded outside the office and starts circulating. A former employee's login still works two weeks after they left, and someone notices it was used at 2 am. Any of these is a personal data breach under the DPDP Act, and the moment you confirm it, a clock starts on two separate duties: telling the travellers affected, and telling the government.

Most five-person agencies have never written down what happens next. There's no incident log, no template message to clients, no clear answer for who calls the Data Protection Board or when. That gap is exactly where a bad night turns into a bad year, because the law doesn't care that you found out at 11 pm on a Saturday.

This post is the response plan: what to do in the first hour, what you must tell affected travellers, what goes to the Board and on what clock, and the five controls that would have kept this from happening at all.

The first hour: contain before you assess

The moment you discover a breach, stop the bleeding before you start counting the damage. Every action below should be logged with a timestamp, because that log is what you'll reference later in any Board report and in your own defence if a client asks what you did.

1. Revoke access. Kill the login, session token or shared-drive permission that caused the exposure. If it's a compromised password, change it everywhere it was reused, not just on the one account.
2. Kill the link. If the breach is a public or "anyone with the link" share, disable it immediately. Screenshot it first if you can, for your own record of what was exposed and for how long.
3. Recover or wipe the device. A lost laptop or phone with local files: trigger remote wipe if you have it set up, or at minimum flag the device with your telecom provider and change every password that was saved on it.
4. Change shared passwords. If the exposed system used a password more than one staff member knew, rotate it and move that system onto individual logins as part of the fix, not after.
5. Freeze, don't delete. Don't delete the exposed file or account activity to "clean it up." You need that evidence to scope the breach properly in the next step, and to show the Board you investigated rather than covered it up.

Write down what happened, what you did, and when, as you do it. Nobody remembers the sequence accurately by the next morning.

Scope it: what you actually need to know before you notify anyone

You cannot write a truthful notification to a traveller or the Board until you know what was actually exposed. Scoping means answering four questions: which files, which travellers, which specific data fields, and how it happened.

Not every exposure is the same weight. A spreadsheet with names and phone numbers is a lower-severity leak than a folder of scanned passports, which typically carries a name, date of birth, passport number, photograph and often a visa or address. The second is far more useful to someone committing identity fraud, and your notification and your own risk assessment should reflect that difference honestly rather than downplaying it.

Work through this before you draft anything:

Question	What you're establishing
What files or systems were exposed	The exact data fields at risk: name only, or name + passport number + photo
How many travellers are affected	Whether this is 3 bookings or 3 seasons of client records
When did exposure start vs. when discovered	The real duration you're liable for, not just the discovery date
How did it happen	Lost device, public link, insider access, stolen login: shapes your fix and your report

Don't skip this step to move faster on notification. A rushed, wrong scope (telling 40 travellers when it was actually 400, or the reverse) creates its own problem, and a fuller picture usually emerges within hours of a proper look at access logs.

What you must tell affected travellers

Under Rule 7(1) of the DPDP Rules 2025, you must intimate each affected traveller without delay, in a concise, clear and plain manner, through their registered contact channel, covering five specific things: what happened, what it means for them, what you've done about it, what they should do, and who they can ask.

That's not a suggestion of good practice, it's what the rule requires you to include (Gazette of India, DPDP Rules 2025, Rule 7(1)):

• A description of the breach: what happened, what data, roughly when.
• The likely consequences for them specifically (identity misuse risk if a passport number leaked; lower risk if it was only a name and phone number).
• What you've done or are doing to contain and fix it.
• What they can do to protect themselves.
• Contact details of a real person at your agency who can answer their questions.

Example: "On 14 May we discovered that a device containing scanned copies of your passport (photo page) was lost. We have disabled remote access to that device and are auditing all files it could access. We recommend you watch for any unusual activity referencing your passport number and inform us immediately if you notice anything. For questions, contact [name] at [phone/email]. We apologise for this and will update you as our review progresses."

Send it through the channel you normally use with that traveller, WhatsApp or email, not buried in a generic notice they'll never open. If your office runs bookings off one shared WhatsApp number across staff, make sure whoever sends this notification is authorised to speak for the agency on it, since a poorly worded personal message from a junior staffer's account can do more damage than the breach itself.

What goes to the Data Protection Board, and on what clock

Rule 7(2) sets a two-stage duty to the Board: an immediate "without delay" first alert describing the basics of the breach, followed by a fuller report within 72 hours of becoming aware, covering causes, mitigation, who caused it, remedial steps, and what you told affected travellers.

The first alert doesn't need to be polished. It needs a description of the breach's nature, extent, timing, location and likely impact, sent as soon as you reasonably can once you know a breach occurred. The follow-up, due within 72 hours (or a longer period the Board grants on a written request), is the detailed version: the facts and circumstances that led to it, mitigation measures taken, findings on who or what caused it, the remedial steps you've put in place to stop a repeat, and a report on what you sent affected travellers (Gazette of India, DPDP Rules 2025, Rule 7(2)).

Once you've filed, the Board can open an inquiry. Under Rule 19(9), it's required to complete that inquiry within six months of receiving your intimation or a complaint, extendable in three-month increments for recorded reasons (Gazette of India, DPDP Rules 2025, Rule 19(9)). That timeline matters for your own planning: a filed breach isn't a closed matter the day you send the report. It can stay open, and be asked about, for months.

Why "the rules aren't fully in force yet" is not the same as "nothing can happen"

The DPDP Rules 2025 were notified on 13 November 2025, but not every rule took effect that day. The Rules' own commencement clause phases them in: the Board's own establishment and functioning provisions went live immediately, while Rule 6 (security safeguards) and Rule 7 (the breach-notification mechanics described above) are deferred roughly 18 months, to around 13 May 2027 (Gazette of India, DPDP Rules 2025, Rule 1(2)-(4)).

That deferral does not mean an agency is safe from any consequence today. The Data Protection Board exists now, and it can receive a complaint now. A traveller who finds out their passport data leaked can still take that complaint somewhere, and the Board's inquiry powers under the Act itself are already operative. Treat "Rule 7 isn't fully binding yet" and "I have nothing to worry about until 2027" as two different claims: the first is currently true on the gazette text, the second is not a safe assumption to build a response plan around.

Careful: This is genuinely unsettled ground, and the gap between "the specific 72-hour mechanic isn't yet in force" and "you have no exposure" is exactly the kind of nuance that gets misquoted. Confirm the current enforcement position with a lawyer before you decide how urgently to act on any specific breach, and don't treat either framing above as settled without that check. This is a companion piece to what the DPDP Act already requires of your agency day to day, which covers the same 18-month runway from the consent and security side.

What failing this actually costs: the penalty math

The Act's Schedule sets a ceiling of up to ₹250 crore for failing to take reasonable security safeguards, and up to ₹200 crore for failing to notify a breach to the Board or affected travellers (DPDP Act 2023, The Schedule; the ₹250 crore figure is independently corroborated by PRS Legislative Research's summary of the Act).

Failure	Maximum penalty (Schedule ceiling)
Failing reasonable security safeguards (Sec. 8(5))	Up to ₹250 crore
Failing to notify a breach (Sec. 8(6))	Up to ₹200 crore
Breach of a Significant Data Fiduciary's extra obligations	Up to ₹150 crore
Breach of any other provision of the Act or Rules	Up to ₹50 crore

These are maxima, not fixed fines. The Board conducts an inquiry and scales any penalty to the nature, gravity and duration of the failure before deciding an amount; it doesn't levy an automatic charge the moment a breach is reported (PRS Legislative Research). The numbers were clearly built with large-scale data processors in mind, not a five-person agency that notified promptly and documented an honest response. That said, "the ceiling is high" is not the same as "the floor is zero," and no enforcement track record against a travel agency exists yet to gauge where a real case would land. Confirm the current penalty and enforcement position with a lawyer before you assume either the worst case or a free pass.

The five controls that would have prevented most of this

Rule 6(1) lists what counts as a reasonable security safeguard: encryption or masking of data, access controls, logging and monitoring to detect unauthorised access, backup and continuity measures, one year of retained logs, and contractual safeguards with anyone you share data with (Gazette of India, DPDP Rules 2025, Rule 6(1)). In practice, for a small agency, that translates into five concrete habits.

1. No passports on personal WhatsApp. Scans forwarded to a staffer's personal number live on a device you don't control and can't wipe. This is an access-control failure the day it happens, breach or not.
2. A written retention-and-deletion rule. Decide how long you keep a passport scan after a trip closes, and actually delete it. Data you no longer hold can't leak.
3. Per-user logins, not one shared password. A shared login means you can never tell, after the fact, who accessed what, which is exactly the logging and monitoring Rule 6(1) expects.
4. A locked, access-controlled shared drive. Not a folder anyone with the link can open. Set it up so access is explicit and revocable per person.
5. A written list of every vendor who's ever received a scan. DMCs, visa agents, insurance partners. If you can't produce this list in an afternoon, you also can't scope a breach quickly when one happens, and you have no contractual safeguard trail with those processors either.

If an employee leaving with client data is part of what worries you here, the access-control habits above are also most of what actually protects you when a staffer walks out with the client list. And if the exposure in question started with a phishing email rather than a lost device, the pattern often looks closer to a supplier-impersonation fraud than a straightforward leak, worth reading if your incident involves a compromised inbox rather than a lost laptop.

A one-page incident log to fill in the moment you discover a breach

Keep this as a template you can open and fill in at 11 pm, not something you design from scratch under pressure.

• Discovered: date, time, who found it, how.
• What was exposed: files/systems, data fields (name only? passport number? photo?), estimated traveller count.
• Containment actions taken: each action with a timestamp (login revoked, link killed, device wiped, password changed).
• Internal notification: who inside the agency was told, and when.
• Traveller intimation: date sent, channel used, confirm it covers all five Rule 7(1) elements (what happened, consequences, mitigation, their safety steps, contact person).
• Board notification decision: filed or not, date of first alert, date of 72-hour follow-up, reasoning if you chose not to file.
• Root cause and fix: what caused it, and what specific control now prevents a repeat.

Filling this in as you go, rather than reconstructing it a week later, is what turns a scramble into a defensible, documented response.

Common questions

What counts as a personal data breach under the DPDP Act?

A personal data breach is any unauthorised access, disclosure, alteration, loss or destruction of personal data, whether accidental or intentional, that compromises its confidentiality, integrity or availability. A lost laptop with passport scans, a public link left open, or a stolen login used to pull client records all qualify. It doesn't require proof that the data was actually misused, only that it was exposed.

What's the actual penalty for a data breach under the DPDP Act 2023?

The Schedule to the Act sets maximum penalties of up to ₹250 crore for failing to take reasonable security safeguards and up to ₹200 crore for failing to notify a breach, decided by the Data Protection Board after an inquiry rather than charged automatically. These are ceilings, not fixed fines, and no enforcement precedent yet exists to show where a small agency's case would actually land. Confirm the current enforcement position with a lawyer rather than assuming either extreme.

How soon do I have to notify the Data Protection Board?

Rule 7(2) requires an initial alert to the Board without delay once you become aware of a breach, followed by a fuller, detailed report within 72 hours (or a longer window the Board grants on written request). Note that the Rules' own commencement clause defers the specific Rule 7 mechanics to roughly May 2027, so confirm with a lawyer whether this 72-hour clock is currently operative for your situation before treating it as settled.

The short version

• A leaked passport scan, a lost device, or a compromised login is a personal data breach under the DPDP Act the moment you confirm it.
• First hour: revoke access, kill any public link, recover or wipe the device, change shared passwords, log every action with a timestamp.
• Scope before you notify: know which files, which travellers, which specific data fields, and how it happened.
• Rule 7(1): tell each affected traveller without delay, covering what happened, the risk to them, your fix, their safety steps, and a contact person.
• Rule 7(2): alert the Board without delay, then file a full report within 72 hours; the Board's own inquiry can then run six months or longer.
• The Rules' 18-month phase-in means the specific 72-hour mechanic isn't yet fully in force as of this writing, but the Board's complaint and inquiry powers already exist. Confirm your current exposure with a lawyer, don't assume either extreme.
• The five controls that prevent most of this: no passports on personal WhatsApp, a written retention rule, per-user logins, an access-controlled shared drive, and a written vendor list.