When your mobile banking platform exposes customer data mid-deployment, you face an immediate decision: roll back the update, suspend the service, or monitor and contain. The wrong choice worsens the breach. The right one limits your notification obligation and preserves customer trust.
This isn't theoretical. Lloyds Banking Group exposed up to 447,936 customers' payment details, account information, and national insurance numbers during a mobile app update on March 12. The bank reported to the Financial Conduct Authority the same morning and notified the Information Commissioner's Office within the 72-hour notification window. But the decision tree that led to those actions started the moment engineers detected the defect.
Here's how to navigate that decision when you're the one receiving the alert.
The Decision You Are Facing
You've deployed a software update. Users can now see data belonging to other users. Your monitoring system flagged anomalous access patterns, or worse, a customer reported seeing someone else's transaction history. You have minutes, not hours, to decide:
- Do you immediately suspend the affected service?
- Do you roll back the deployment?
- Do you implement a containment measure and monitor?
Each path triggers different regulatory, operational, and reputational consequences. GDPR Article 33 starts your 72-hour clock the moment you become "aware" of the breach, and awareness begins when your technical team confirms unauthorized disclosure, not when legal finishes the impact assessment.
Key Factors That Affect Your Choice
Exposure window. How long has the defect been live? Lloyds' glitch required users to view their app within "small fractions of a second" of other users. If your exposure window is measured in milliseconds per affected user, containment may suffice. If it's continuous, you need immediate suspension.
Data category. Payment references and national insurance numbers fall under GDPR Article 9's special category threshold if they reveal health data, but they always constitute high-risk processing when combined with financial account details. If your breach exposes credentials, authentication tokens, or data that enables account takeover, suspend first and assess second.
Access evidence. Can you determine who accessed what? Lloyds identified 114,182 customers who clicked into transactions revealing others' details. If your logging infrastructure can't produce that count, you're operating blind, which shifts you toward the most conservative path.
Containment feasibility. Can you deploy a fix without suspending the service? If your architecture allows you to patch the defect in place, and your monitoring confirms no ongoing unauthorized access, containment becomes viable. If the fix requires a full rollback and redeployment, you're weighing service continuity against breach expansion.
Path A: Immediate Suspension
Choose this when:
- The defect enables continuous, uncontrolled access to special category data or authentication credentials.
- Your logging infrastructure cannot identify affected users or quantify exposure.
- The breach involves third-party data subjects (not just your customers), which expands your notification to supervisory authority obligation.
- You cannot deploy a containment fix within the time it would take to suspend and roll back.
What this triggers:
You'll face customer complaints about service unavailability, but you've stopped the breach expansion. Your notification to the supervisory authority under Article 33 must describe the suspension as a technical and organizational measure to mitigate harm. Document the timestamp of your suspension decision; this becomes your evidence of "without undue delay" compliance.
You'll need a communication plan for customers. Lloyds asked users to delete screenshots or recorded information, but that request only works if you can identify who accessed what. Suspension buys you time to build that list before you notify affected individuals under Article 34.
Path B: Containment and Monitoring
Choose this when:
- You can deploy a fix that stops unauthorized access without suspending the service.
- Your monitoring confirms the exposure window was narrow (seconds or minutes, not hours).
- The data disclosed does not include credentials or special category data.
- Your logging can produce an exact count of affected users and accessed records.
What this triggers:
You're still notifying the supervisory authority within 72 hours, but your breach description includes the containment measure and the evidence that no ongoing access is occurring. This is the path Lloyds appears to have taken: the bank reported to the Financial Conduct Authority on the morning of March 12 and implemented monitoring for fraud and misuse.
Your fraud monitoring becomes part of your supplementary measures to demonstrate you've reduced the risk to data subjects. If you're paying compensation (Lloyds paid £139,000 to 3,625 customers), that's evidence of harm acknowledgment, not necessarily financial loss. Track every compensation request; it feeds your breach register and informs your next prior consultation with the supervisory authority if this processing activity qualifies as high-risk processing.
Path C: Rollback and Root Cause Analysis
Choose this when:
- The defect is part of a larger update that introduced multiple changes.
- You cannot isolate the specific code path causing unauthorized access.
- Containment would require disabling core functionality.
- You have a stable previous version to revert to.
What this triggers:
Rollback is suspension with a clear remediation path. You're telling customers and regulators that you've restored a known-good state while you investigate. Your 72-hour notification still applies, but your description of measures taken includes the rollback timestamp and the version you reverted to.
Root cause analysis here isn't optional. If your deployment process allowed a defect that exposed nearly 500,000 customers' data to reach production, your Technical and Organisational Measures failed. The supervisory authority will expect you to describe what changed in your release process, not just what you fixed in the code.
Summary Matrix
| Factor | Suspend | Contain | Rollback |
|---|---|---|---|
| Exposure window | Continuous or unknown | Narrow (seconds/minutes) | Intermittent or unclear |
| Data category | Special category or credentials | Payment details, account info | Any category if root cause unclear |
| Access evidence | Cannot quantify | Can produce exact count | Partial logging |
| Fix feasibility | Requires full redeployment | Can patch in place | Stable previous version available |
| Service impact | High (customers locked out) | Low (service continues) | Medium (temporary outage) |
| Regulatory description | "Suspended service to prevent further unauthorized access" | "Deployed containment fix and monitoring" | "Reverted to stable version pending investigation" |
Your decision compounds or contains the breach. Lloyds reported within hours, identified affected users, and implemented monitoring. But the bank's letter to the Treasury select committee also acknowledged the trade-off: digital banking efficiency creates technology risk that customers must understand. Your job is to ensure that when the defect reaches production, your response doesn't become the second failure.
