When Daiichi Kosho discovered a malware infection at Nippon Columbia Group had potentially exposed 8,724,000 customer records, the company faced a scenario most privacy teams dread: your data protection is only as strong as your weakest processor. But the breach itself wasn't the only problem. The real damage often comes from how you prepare for and respond to third-party incidents.
Why These Mistakes Keep Happening
Third-party risk management is often fragmented. Your legal team treats it as a contracting issue, your security team sees it as a technical assessment, and your privacy function views it through a compliance lens. This fragmentation means no one owns the end-to-end risk, and critical gaps emerge.
The GDPR Article 28 obligations are clear: you must only engage processors that provide sufficient guarantees to implement appropriate technical and organizational measures. But "sufficient guarantees" is where teams stumble. They mistake a signed data processing agreement for actual security assurance or conduct a thorough processor assessment once and never revisit it.
Mistake 1: Treating the supervisory authority as Your Risk Assessment
Why it happens: Your procurement team secures a signed data processing agreement, and everyone assumes the box is ticked. The supervisory authority includes standard security commitments, so it feels like you've done your Article 28 due diligence.
The consequence: A supervisory authority is a legal instrument, not a security evaluation. It tells you what the processor has committed to do, not what they actually do or how well they do it. When the Nippon Columbia Group malware infection occurred between October 1 and October 2, the existence of a supervisory authority didn't prevent the breach or limit its scope.
The fix: Separate your legal contracting from your security assessment. Before you sign any supervisory authority, require evidence of the processor's security posture: recent SOC 2 reports, penetration test results, incident response procedures, and employee security training records. For processors handling significant volumes of personal data, conduct on-site or virtual security audits. Document your assessment and the specific measures that gave you confidence they meet Article 28's "sufficient guarantees" threshold. Store this documentation separately from the contract, because your supervisory authority will want to see your decision-making process, not just your signed agreement.
Mistake 2: No Defined Breach Notification Path from Processor to You
Why it happens: Article 33 requires you to notify your supervisory authority within 72 hours of becoming aware of a personal data breach. But teams assume "becoming aware" starts when the processor tells them. They don't specify exactly how and how quickly that notification must happen.
The consequence: Daiichi Kosho discovered the malware infection on October 1-2, but received the report from Nippon Columbia Group on October 5. That's a three-to-four-day delay before the controller even knew about the incident. Your 72-hour clock may have already burned through half its time before you can begin your own assessment and notification obligations.
The fix: Your supervisory authority must specify breach notification timelines that give you room to meet your own obligations. Require notification within 24 hours of the processor discovering the incident, not after they complete their investigation. Define what constitutes "discovery": is it when their monitoring alerts fire, when an analyst confirms the alert, or when management approves disclosure? Require an immediate preliminary notice with whatever facts are known, followed by detailed updates every 24 hours. Include specific contact details (not a general info@ address) and require the processor to maintain an on-call security contact who can be reached outside business hours.
Mistake 3: No Pre-Defined Incident Response Roles for Processor Breaches
Why it happens: Your incident response plan covers breaches of your own systems. It assigns roles, defines escalation paths, and specifies who makes notification decisions. But it doesn't account for breaches at processors, where you have less visibility and control but the same legal obligations.
The consequence: When a processor reports a breach, your team scrambles to figure out who's responsible for what. Does your security team lead the response, or your privacy function? Who interfaces with the processor's team? Who's gathering the facts needed for supervisory authority notification? This confusion burns through your 72-hour window and often results in incomplete or inaccurate initial notifications that you must later supplement.
The fix: Create a specific processor breach response protocol within your incident response plan. Designate a processor breach coordinator (often your DPO or a senior privacy analyst) who owns the response. Define their authority to request information from the processor, make preliminary notification decisions, and escalate to executive leadership. Document the specific information you need from the processor: what data was affected, how many data subjects, what categories of personal data, what security measures were in place, what measures they've taken to mitigate harm. Require your processors to participate in an annual tabletop exercise where you simulate a breach at their environment and practice the notification and response procedures.
Mistake 4: Inadequate Visibility into What Data Your Processor Actually Holds
Why it happens: You know what data you send to processors for defined purposes. What you often don't know is what they retain, how long they keep it, or whether they create derived data from your information.
The consequence: When Nippon Columbia Group discovered the malware infection, Daiichi Kosho learned that "personal data related to work outsourced to us was temporarily stored on the device in question." That word "temporarily" suggests data that shouldn't have been there long-term, or perhaps shouldn't have been on an employee device at all. Without clear data flow documentation, you can't quickly determine the breach's scope or accurately notify affected data subjects.
The fix: Map the complete data flow to and from each processor. Document not just what you send, but what they generate, what they retain after the processing purpose is fulfilled, and where data is stored (including employee devices, if permitted). Require processors to maintain and share an updated data inventory quarterly. For high-risk processing, implement technical controls that give you visibility: audit logs you can access, data loss prevention alerts that copy to your security team, or encryption where you control the keys. When you conduct processor audits, specifically verify that data is only present in the locations and formats your data flow documentation describes.
Mistake 5: No Communication Plan for Data Subjects After a Processor Breach
Why it happens: Article 34 requires you to communicate personal data breaches to affected data subjects when the breach is likely to result in high risk to their rights and freedoms. Teams assume they'll figure out the communication if and when it's needed.
The consequence: Daiichi Kosho advised customers to "be extremely careful of suspicious emails, SMS messages and phone calls" and clarified that "we will never ask you for your password or credit card information." This guidance is helpful, but it came six days after the breach discovery. Data subjects potentially exposed to phishing attempts had nearly a week of vulnerability before receiving any protective guidance.
The fix: Pre-draft data subject notification templates for common processor breach scenarios. Include specific protective actions data subjects should take (not generic "be vigilant" language), contact information for questions, and a clear explanation of what happened without legal jargon. Determine your notification method in advance: email, SMS, postal mail, or account login notifications. For processors handling data that creates high phishing risk (contact details, account information), require them to notify you within hours, not days, so you can warn data subjects before attackers exploit the breach. Consider offering affected data subjects identity monitoring or fraud protection services, and have processor relationships in place so you can activate these services immediately rather than negotiating contracts during an active incident.
Prevention Checklist
Before you onboard your next processor, verify:
- You've conducted a security assessment separate from contract negotiation, and documented the specific measures that satisfy Article 28's requirements
- Your supervisory authority specifies breach notification within 24 hours of discovery, with "discovery" clearly defined
- Your supervisory authority includes specific security contact details and requires 24/7 availability during incidents
- Your incident response plan includes a processor breach protocol with assigned roles and decision authority
- You've documented the complete data flow to and from the processor, including derived data and retention periods
- You have technical visibility into where your data resides at the processor (audit logs, monitoring, or encryption controls)
- You've pre-drafted data subject notification templates for likely processor breach scenarios
- Your processor has participated in a tabletop exercise simulating a breach at their environment
- You've identified which processor relationships create high risk and established more frequent audit schedules for those relationships
- You have a documented process for periodic re-assessment of processor security, not just at onboarding
Your processor relationships extend your attack surface and your compliance obligations. The question isn't whether a processor will eventually experience a security incident. The question is whether you'll find out in time to meet your obligations and protect your data subjects.
