What-if scenarios every Data Protection Officer should rehearse before they're real

I've been a Data Protection Officer at three different organisations and I've coached about a dozen more into the role. The pattern is always the same. The first month is spent learning the systems. The second month is spent reading the Act. The third month is spent feeling competent. And then somewhere in month four or five, the first real incident lands and the DPO realises they have no muscle memory for it. They've read every clause of Section 8(6) on breach notification, but they've never actually done a breach notification, and now they have 72 hours and a nervous CEO and a complainant on the phone.

The fix is rehearsal. I run my new DPOs through six what-if scenarios in their first month, deliberately, while there's no real fire. Each one is calibrated to a different failure mode. None of them have a clean answer. The point isn't to memorise a script — it's to find out where your organisation's reflexes are weak before someone discovers it for you.

Here are the six. Try them on yourself.

Scenario 1 — The Saturday morning email

It is 7:42 am on a Saturday. You wake up to an email from your security team's monitoring service. A flag fired overnight: an unusual volume of database queries from a service account that normally runs a once-a-day batch job. The security analyst on call thinks there might be a credential leak. They can't say yet whether personal data was exfiltrated.

Section 8(6) of the DPDP Act says the Data Fiduciary "shall, in the event of a personal data breach, give the Board and each affected Data Principal, intimation of such breach in such form and manner as may be prescribed." The 2025 Rules pin the Board notification at 72 hours from the moment of awareness.

What is your first move?

The wrong answer is: "I'll wait until they confirm whether it's actually a breach." The right answer is: I start the clock. The 72 hours begins from the moment you become aware of facts that suggest a breach may have occurred, not from the moment forensics conclusively prove one. If you wait 36 hours for the security team to give you certainty, you've burned half your window on the wrong activity.

What you actually do in the first 30 minutes:

• Acknowledge the alert and write down the time of awareness in your incident log
• Page your incident commander (which might be you)
• Open a dedicated Slack channel or war room thread
• Notify your General Counsel and your CISO
• Ask the security team three questions: which records, how many, what classes of personal data
• Tell them you need a preliminary answer in 4 hours, not 24

The thing every DPO forgets in this moment: you don't need to know it's a breach to begin notification preparation. You need a draft Board notification, a draft Data Principal notification, and a templated set of facts you can fill in as the investigation progresses. If you wait until you're certain, the writing is what kills you.

Rehearsal value: This scenario teaches the DPO that "awareness" is a legal concept, not a forensic one, and that the 72-hour clock begins on a vibe.

Scenario 2 — The deletion request you can't fulfil

A Data Principal (let's call her Reema) emails your grievance inbox: "Under Section 12 of the DPDP Act, I am requesting erasure of all my personal data held by your organisation. Please confirm completion within 7 days."

You acknowledge the request and route it to your engineering team. They come back two days later with bad news. Reema's data is in the production database (deletable). It's in the analytics warehouse (where you've already aggregated it into cohort metrics — deletable in theory, but the cohort metrics will be slightly wrong if you remove her). It's in nightly database backups going back 90 days (not easily deletable without restoring and re-snapshotting). It's in your customer support tool's transcript history (deletable). And it's in last quarter's billing PDF that you sent to your auditor (uneditable, archival).

What do you do, and what do you tell Reema?

The honest answer is that the DPDP Act does not require you to perform impossible deletion. Section 8(7) says the Fiduciary shall erase personal data when the purpose for which it was collected is no longer being served, unless retention is necessary for compliance with any law. Backups, audit trail copies, and statutory financial records often fall under that exception.

What you tell Reema:

• We have erased your personal data from [list of systems]
• We have placed a deletion marker on your record in our backups; your data will be permanently removed when the next 90-day backup rotation completes on [date]
• We are required by [law/regulation] to retain certain records for [period]; those records will be erased on [date]
• We will not use any of the above for any purpose other than meeting our legal obligations
• A summary of this action has been added to your file

The thing every DPO discovers in this moment: your organisation's actual data flows are messier than your data map says they are. You'll find a system you forgot existed. You'll find an export that someone made for a one-off analysis last year and never deleted. You'll find a CSV in someone's email attachment.

Rehearsal value: This teaches the DPO that data inventories are not "set up once and trust forever" — they need a quarterly walk-through to catch the systems that crept in.

Scenario 3 — The board member who wants the customer list

Your CEO copies you on an email. The board chair wants a sample of your top 50 customers to share at next week's investor showcase. "Could marketing put together a one-pager with names, designations, and any quotable testimonials?"

The CEO is asking. The board chair is approving. The marketing team is ready to send. Where do you draw the line?

The DPDP Act doesn't prohibit marketing or testimonials, but it does require specific, informed, freely-given consent (Section 6) for the specific purpose of public-facing use of someone's name, designation, or quote. The consent your customers gave you when they signed your terms of service was for the operation of the service — not for inclusion in an investor pitch deck.

What do you say?

You say: "Yes, we can do this — but every individual on the list needs to be asked for consent in writing, with an opt-out path, and we should not include anyone who declines. I'll work with marketing on the consent language. Realistic timeline: ten working days, not three."

The hard part is that this is a tiny request from a powerful person. The temptation is to nod and let it happen. The cost of nodding is that you've now created a complaint vector — any one of those customers can write to the Data Protection Board and say "I was named in their public marketing without my consent." That's a Section 33 violation, and it's small but it's a perfect example of the kind of thing the Board is going to enjoy enforcing because it's clean and uncontroversial.

Rehearsal value: This teaches the DPO that the most dangerous Section 33 complaints are not the dramatic breaches — they're the small, casual, "we always did it this way" violations that nobody thought twice about.

Scenario 4 — The vendor that just changed its data residency

Your sales-ops platform sends an email to all customers: "We're excited to announce that we're consolidating our infrastructure to our US and EU regions for performance reasons. Indian customer data will be moved to our Frankfurt cluster over the next 30 days."

You are an Indian Data Fiduciary using this platform to manage your customer pipeline. Some of those customers' personal data — names, emails, designations, deal stages — will now be sitting on a European server. Section 16 of the Act gives the Central Government the power to restrict transfers to specific countries.

What do you do?

First, check whether Germany is currently on a restricted list. (It isn't.) Then check whether your Data Processing Agreement with the vendor anticipated cross-border transfers and whether the vendor's notice satisfies the contractual requirement to inform you. (It might not.) Then check whether your own privacy notices and consent records told your customers that their data could be transferred to "a third country in Europe." (They probably didn't.)

Now you have three problems:

1. Update your privacy notices to reflect the new processing location
2. Re-notify your customers under Section 5 — the notice has to be re-issued when the processing changes materially
3. Decide whether to keep using the vendor or migrate to one that hosts in India

The third question is the strategic one. You don't have to migrate. But every cross-border vendor is a Section 16 risk: a future government notification could restrict transfers to that destination, and you'd be caught flat-footed. The defensive posture is to prefer India-resident infrastructure when the choice is available.

Rehearsal value: This teaches the DPO that compliance is not a one-time decision — your vendor stack will change underneath you and every change is a notice + consent re-validation event.

Scenario 5 — The grievance with no good answer

A complainant writes to your grievance inbox. He claims your support team disclosed his account details to an unauthorised third party who called pretending to be him. He attaches a recording of the call. The recording is real. Your support agent did, in fact, hand over account details after a perfunctory verification.

Section 13 of the Act gives every Data Principal the right to grievance redressal and requires Fiduciaries to respond within a defined window. Section 33 sets the penalty for failing to take reasonable security safeguards, including against unauthorised disclosure, at up to ₹250 crore per instance. The complainant tells you he is also writing to the Data Protection Board in parallel.

What do you do?

The wrong answer is to defend the support agent. They did what their training told them to do, but the training was wrong. The right answer is to:

1. Acknowledge the complaint immediately in writing, with an incident ID and an investigation timeline
2. Quarantine the affected account so no further information can be released
3. Run a forensic review of every interaction with that account in the last 12 months
4. Notify the complainant of the specific data points that were disclosed
5. Notify the Data Protection Board (yes, voluntarily — Section 8(6) is best read as a floor, not a ceiling)
6. Update the support team's verification protocol so the next caller cannot succeed the same way
7. Document everything

Then you brace for the Board's investigation. Your defence will not be "this was an isolated incident." Your defence will be "we identified the gap immediately, we self-reported, we remediated within X days, and we updated our controls to prevent recurrence."

Rehearsal value: This teaches the DPO that the right move when caught is to over-cooperate, not to minimise. The Board's penalty calculus weights remediation effort heavily.

Scenario 6 — The CEO who doesn't want to spend money

Your CEO calls you in for a one-on-one. "You've been talking about this DPDP thing for three months now. I've looked at the budget you submitted. It's a lot of money. I need you to tell me what's the minimum we can do without getting in trouble."

This is the scenario that determines whether you'll be a real DPO or a decorative one.

The wrong answer is to tell the CEO what they want to hear and then quietly worry about it on your own. The right answer is to be quantitative:

"Without [item A], our exposure on Section 8(6) is up to ₹250 crore per breach. The probability of a breach in the next 18 months at our current security posture is non-trivial — our last pen test found [these issues]. So [item A] is non-negotiable.

Without [item B], we cannot honour Data Principal rights requests within the statutory window. Each unfulfilled request is a Section 33 complaint vector. We're currently receiving about [N] requests per month. So [item B] is non-negotiable.

Items C and D are quality-of-life — they reduce the cost of compliance over time but they're not penalty-prevention. We can defer them by one quarter without legal exposure, as long as we revisit before [date]."

What this conversation does is convert "spending money on compliance" into "buying down a specific quantified risk." Once it's framed that way, the CEO can make a real decision rather than a gut-feel one.

Rehearsal value: This teaches the DPO that their job isn't to enforce the law — it's to translate the law into business risk language and let the executives make informed decisions. If they make the wrong decision, your job is to document the recommendation, the warning, and the override, in writing, signed off by the executive.

What rehearsal actually does

Each of these scenarios has a different "tell" — a place where the DPO's organisation will fail if they haven't built the muscle yet. Scenario 1 tests your incident clock. Scenario 2 tests your data inventory. Scenario 3 tests your spine. Scenario 4 tests your vendor governance. Scenario 5 tests your willingness to self-disclose. Scenario 6 tests your ability to translate legalese into board-room language.

Run each one with your team as a tabletop exercise. Don't tell them in advance which scenario is coming. Time-box the response to the same windows the real incident would impose. At the end, debrief honestly: where did we have to invent a process on the fly? Where did we discover a system that wasn't on our data map? Where did we hesitate on a decision that should have been automatic?

The answers to those questions are your work plan for the next quarter. The DPOs who do this rehearsal land on incidents with a calm, prepared posture. The DPOs who don't end up doing all the same work — but compressed into the worst 72 hours of their professional lives, with the regulator watching.

I know which version I'd rather be.