Questions started landing in my inbox after a Canadian supervisory authority announced its investigation into Human Resources and Skills Development Canada following a breach affecting student loan recipients. This news triggered a familiar panic: realizing that your breach response plan might be more aspirational than operational.
Here are the questions I heard most often from privacy teams trying to stress-test their readiness. The answers draw from GDPR requirements, supervisory authority expectations, and practical strategies when you're under scrutiny.
Q1: Our breach plan says "notify within 72 hours" but who actually makes that call?
You do. More precisely, the controller does, but in practice, it's usually the DPO or privacy lead who assesses whether the breach meets the Article 33 threshold.
Here's what that assessment looks like: Did the breach create a risk to individuals' rights and freedoms? Not "could it theoretically" but does this specific incident, with these specific circumstances, pose an actual risk? You're evaluating the likelihood and severity of impact, not just the fact that data left your control.
The decision-maker needs direct access to the incident response team and enough context to judge impact. If your plan lists the DPO as decision-maker but they learn about breaches from weekly reports, you've got a structural problem. The 72-hour clock starts when you become aware of the breach, not when someone remembers to loop in privacy.
Make accountability explicit in your plan: "The DPO will be notified within 2 hours of incident detection and will determine notification requirements within 12 hours of initial assessment." Then test whether those timelines work.
Q2: What does "investigation" actually mean for us day-to-day?
It means you'll produce a lot of documentation, quickly, and it needs to tell a coherent story.
When a supervisory authority launches an investigation, they're typically asking: What happened? What was the controller doing before the breach to prevent it? What did they do after to contain it? What's changed to prevent recurrence?
Your day-to-day shifts to evidence gathering. You'll need processing records, logs showing when you detected the breach, communications showing how you assessed it, your notification to the supervisory authority (if required), any notifications to affected individuals, and documentation of remedial measures.
The teams that handle investigations well have two things in place beforehand: centralized records of processing activities (Article 30 isn't optional) and a clear chain of custody for breach-related decisions. If you're scrambling to reconstruct what data you were processing or why you made certain containment decisions, the investigation becomes exponentially harder.
Q3: We run annual security audits. Isn't that enough to show we're taking this seriously?
Annual audits are a baseline, not a defense.
Supervisory authorities expect you to identify and address risks on an ongoing basis, particularly for high-risk processing. If you're handling sensitive categories of personal data or processing at scale, annual reviews won't catch emerging vulnerabilities fast enough.
Consider data protection impact assessments (DPIAs) for any new processing that's likely to result in high risk. Article 35 requires them, and they force you to think through risks before they become breaches. More importantly, they create documentation showing you assessed risk, identified measures to mitigate it, and made informed decisions about residual risk.
Organizations that fare better in investigations can show continuous monitoring, not just point-in-time audits. That might mean quarterly reviews of high-risk systems, ongoing processor assessments, or regular testing of appropriate technical and organizational measures. The frequency should match the risk profile of what you're processing.
Q4: How much detail do we actually need in our breach response plan?
Enough that someone who wasn't involved in writing it can execute it under pressure.
Your plan should specify roles (who leads containment, who assesses notification requirements, who communicates with affected individuals), communication protocols (how does IT alert privacy, how does privacy reach legal), and decision trees for common scenarios.
But here's what matters more than length: Does your team know where the plan lives? Have they practiced using it? Can your IT team find the DPO's contact details at 2 a.m. on a Saturday?
I've reviewed 50-page breach plans that failed because no one had read them. I've seen 8-page plans work because the team ran quarterly tabletop exercises. The sophistication of your plan matters less than whether it's actually operational.
Test the communication chains specifically. If your plan assumes the IT security team will immediately notify the DPO, verify that IT security knows who the DPO is and has current contact details. If it assumes you can pull processing records within hours, try doing that during your next drill.
Q5: What's the first thing a supervisory authority will ask for?
Your Article 30 record of processing activities and your breach notification if you filed one.
They want to understand what you were processing, why you were processing it, who had access, and what measures were in place. If you can't produce a current, accurate record of processing activities, that's a compliance gap independent of the breach itself.
If you notified under Article 33, they'll compare what you told them initially against what you learned subsequently. Inconsistencies aren't necessarily problems (investigations uncover new facts) but unexplained changes in your account raise questions.
Have your documentation organized before you need it. That means maintaining your Article 30 records as processing changes, not reconstructing them when an incident hits.
Q6: Our exec team wants to know: what actually reduces our risk here?
Three things, in order of impact:
First, know what personal data you're processing and where it lives. You can't protect what you can't inventory. This isn't theoretical: when a breach happens, you need to know immediately what was exposed.
Second, implement and test appropriate technical and organizational measures for your actual risk profile. Encryption at rest matters more for some processing than others. Access controls matter universally. Match your measures to what you're protecting.
Third, practice your breach response before you need it. Run scenarios. Test notification timelines. Verify that your communication chains work. The Human Resources and Skills Development Canada investigation reminds us that supervisory authorities will scrutinize not just whether you had measures in place, but whether they were adequate and whether you followed them.
None of this eliminates breach risk, but it significantly changes how an investigation unfolds. You're demonstrating accountability, which is what Article 5(2) requires.
Where to go from here
If these questions surfaced gaps in your program, start with your Article 30 records and your breach response plan. Make sure both reflect your current processing reality, not what you documented eighteen months ago.
Then test your breach response with a tabletop exercise. You don't need an elaborate simulation, just a scenario that forces your team to walk through notification decisions and communication protocols.
The teams that handle investigations well aren't the ones who never have breaches. They're the ones who can show they took their obligations seriously before, during, and after the incident.
