When a processor like Fakturownia suffers a personal data breach affecting more than 600,000 businesses, you need a documented response protocol that your team can execute without improvising under pressure. This checklist guides you through the immediate actions, communication triggers, and validation steps required when a third-party processor notifies you of unauthorized access to personal data you control.
Purpose of This Checklist
This checklist helps you fulfill your obligations under Articles 28, 33, and 34 when a processor experiences a personal data breach. As the controller, you own the 72-hour notification clock to your supervisory authority and the decision about whether to notify affected data subjects. The processor must alert you "without undue delay" per Article 28(3)(f), but they can't make breach notification decisions for you.
Use this checklist when:
- A processor notifies you of unauthorized access to personal data.
- You receive breach indicators from monitoring tools before formal processor notification.
- A processor's security incident appears in public reporting before you receive direct notice.
- The processor integrates with critical infrastructure or government systems, like Fakturownia's connection to Poland's National e-Invoicing System.
Prerequisites
Before executing this checklist, ensure you have:
Documented processor relationships: Current Article 28 processing agreements specifying breach notification procedures, including contact escalation paths and maximum notification timeframes.
Breach notification procedure: Internal protocol defining who assesses breach severity, who has authority to notify the supervisory authority, and who drafts data subject communications.
Personal data inventory: Records of what categories of personal data each processor handles, where it's stored, and which data subjects it relates to (customers, employees, business contacts).
Supervisory authority credentials: Active account and submission method for your supervisory authority's breach notification system.
The Checklist
Hour 0-2: Initial Processor Notification Received
- Record notification timestamp: Document when you received the processor's breach notice. This starts your internal clock, not the 72-hour supervisory authority deadline.
- Activate response team: Notify your DPO, legal counsel, IT security lead, and business owner of the affected processing activity.
- Request processor's initial assessment: Ask for:
- Nature of the breach (unauthorized access, exfiltration, encryption failure).
- Categories of personal data affected.
- Approximate number of data subjects.
- Timeframe of unauthorized access.
- Current containment status.
- Evidence the breach has been stopped.
Hour 2-8: Assess Controller Obligations
- Determine if Article 33 notification required: Does the breach present a risk to data subjects' rights and freedoms? Consider:
- Sensitivity of data (e.g., authentication tokens and password hashes create credential stuffing risk).
- Volume of records (e.g., 6 terabytes of invoices affects business relationships and commercial confidentiality).
- Existing safeguards (e.g., were password hashes salted? Were tokens rotated immediately?).
- Calculate notification deadline: If Article 33 applies, you have 72 hours from when you became aware. "Aware" means when you had sufficient information to determine a breach occurred, not when you received the first vague alert.
- Draft supervisory authority notification: Prepare the Article 33 elements:
- Nature of breach and categories/approximate numbers affected.
- Name and contact details of your DPO.
- Likely consequences of the breach.
- Measures taken or proposed to address the breach and mitigate harm.
- Assess Article 34 direct notification requirement: Does the breach create a high risk to data subjects? If yes, you must notify affected individuals directly unless:
- You implemented appropriate technical and organizational measures that render data unintelligible (e.g., encryption).
- You took subsequent measures ensuring high risk is no longer likely.
- Direct notification would involve disproportionate effort (then use public communication).
Hour 8-24: Secure Your Environment
- Force credential rotation: If authentication tokens or password hashes were exposed:
- Invalidate all API keys and integration tokens for the affected processor.
- Require password resets for any users whose credentials the processor held.
- Review access logs for your systems for signs the compromised credentials were used.
- Review processor access: Temporarily restrict the processor's access to your systems until you confirm containment.
- Check for lateral exposure: If the processor integrates with other systems, verify those connections weren't compromised.
Hour 24-48: Communication Decisions
- Finalize supervisory authority notification: Submit through your supervisory authority's designated channel before the 72-hour deadline.
- Draft data subject communication (if Article 34 applies): Write in clear, plain language:
- What happened and when you learned about it.
- What categories of their personal data were affected.
- What you're doing to contain harm.
- What they should do (change passwords, monitor accounts, watch for phishing).
- How to contact you with questions.
- Prepare stakeholder communications: Brief executives, customer-facing teams, and any business partners who may be affected.
- Document your Article 34 decision: If you decide direct notification isn't required, record your reasoning (e.g., data was encrypted, risk mitigated by processor's immediate token rotation).
Hour 48-72: Accountability and Lessons
- Preserve evidence: Save the processor's breach notifications, your assessment notes, and all communications.
- Review processor contract: Does the processor's response meet their Article 28 obligations? Did they notify you "without undue delay"? Did they provide sufficient information?
- Schedule post-incident review: Plan a meeting within two weeks to assess:
- Whether your processor selection and monitoring processes need adjustment.
- Whether your Article 28 agreements need stronger breach notification language.
- Whether you need additional technical measures (e.g., data minimization, encryption requirements).
Customizing the Checklist
Adjust notification thresholds based on your risk profile: If you process special category data under Article 9 or handle children's data, lower your threshold for Article 34 direct notification. A breach that might be "risk" for a B2B invoicing platform becomes "high risk" when health records or biometric data are involved.
Add industry-specific steps: Financial services firms should notify their financial supervisory authority in addition to the supervisory authority. Healthcare organizations may have separate breach notification obligations under sector-specific law.
Tailor communication templates: Draft skeleton versions of your supervisory authority notification and data subject communication now, with bracketed fields for incident-specific details. You won't write clearly at 2 AM on hour 70 of your notification deadline.
Scale the response team: Smaller organizations may collapse several roles onto one person. Larger organizations should define clear escalation: who assesses, who decides, who notifies, who communicates externally.
Validation Steps
After using this checklist in a real incident or a tabletop exercise:
Check completeness: Did you meet all Article 33 notification elements? Did you document your Article 34 decision with clear reasoning?
Verify timing: Did you submit your supervisory authority notification within 72 hours of awareness? Can you prove when you became aware?
Assess communication quality: If you notified data subjects, was the message clear enough that a non-technical reader understands what happened and what they should do?
Review processor performance: Did the processor meet their contractual notification timeline? Did they provide sufficient technical detail for you to assess risk?
Update your processor risk register: Document this incident in your processor risk management system. If the processor's response was inadequate, escalate to contract review or processor replacement discussions.
The Fakturownia breach shows why you can't delegate breach response to your processors. They must tell you what happened, but you decide what it means for your data subjects and whether notification is required. This checklist ensures you make those decisions systematically, even when the processor's initial notice is incomplete or arrives at midnight.
