The Conduent settlement, with its $80 million penalty for a breach affecting 62.2 million people, wasn't an isolated incident. It's the predictable outcome of recurring mistakes organizations make in managing third-party data relationships. The breach began on October 21, 2024, and went undetected for nearly three months. This timeline highlights fundamental issues that existed before the attackers even arrived.
Why These Mistakes Keep Happening
Third-party risk management often fails because it's treated as a procurement checkbox instead of an ongoing operational discipline. You might sign a Business Associate Agreement, review a SOC 2 report, and move on. Meanwhile, your vendor processes millions of records in systems you've never audited, under security controls you've never tested, with incident response procedures you've never validated.
The hub-and-spoke model, where one vendor holds data from multiple clients, amplifies every weakness. When Conduent's systems were compromised, the breach affected data from dozens of clients, each with different contractual terms.
Mistake 1: Treating Vendor Assessments as Point-in-Time Events
Why it happens: You review security documentation during procurement, get comfortable with the vendor's certifications, and assume those controls remain effective indefinitely.
The consequence: Controls degrade, staff turns over, and systems change. The SOC 2 report you reviewed 18 months ago doesn't reflect the vendor's current security posture. In Conduent's case, attackers maintained access for nearly three months. Continuous monitoring could have detected this persistent access.
The fix: Implement quarterly security validation cycles. Don't just request updated reports; validate specific controls that protect your data. If the vendor processes health information, verify encryption at rest, test access logging, and confirm that your data is logically segregated from other clients' data. Document these validations in your processing records under Article 28(3)(h) GDPR, which requires you to make available all information necessary to demonstrate compliance with controller obligations.
Mistake 2: Failing to Classify Data Before You Share It
Why it happens: You focus on the business function the vendor performs rather than the specific data elements they'll process. The contract might say "back-office support services," but what data does that actually require?
The consequence: Vendors receive more data than needed. Conduent held names, addresses, dates of birth, Social Security numbers, health insurance details, and medical information. For each affected individual, ask: did the vendor's specific function require all of those elements? The settlement documents note that approximately 40 million people had their information stored in "complex backup files" that weren't readily accessible, suggesting data was retained beyond operational necessity.
The fix: Map data elements to specific processing purposes before sharing anything. If the vendor handles payment processing, they don't need diagnosis codes. If they manage appointment scheduling, they don't need Social Security numbers. Create a data inventory specifying what you're sharing, why the vendor needs it, where it will be stored, and how long it will be retained. This is required under Article 5(1)(c) GDPR (data minimization) and Article 28(3)(a) (processing only on documented instructions).
Mistake 3: Accepting Vendor-Standard Data Handling Terms
Why it happens: The vendor presents their standard processing agreement, and you accept it to avoid delaying the project. Negotiating data-specific terms feels like friction.
The consequence: You have no enforceable rights around data location, backup procedures, or deletion timelines. The Conduent settlement reveals that compromised data was stored in two different ways: some in readily accessible systems, others in complex backup files. You should have specified exactly how and where your data would be stored, how backups would be secured, and how quickly data would be purged when no longer needed.
The fix: Negotiate specific data handling schedules as contract appendices. Specify encryption requirements (algorithm and key management), data location restrictions (if you're subject to Chapter V GDPR transfer rules), backup retention limits, and deletion procedures. Include the right to audit these controls, not just review reports. Under Article 28(3)(h), you can require the processor to make available all information necessary to demonstrate compliance, but only if your contract grants you that right.
Mistake 4: Ignoring Detection Gaps in Vendor Environments
Why it happens: You assume the vendor's security team will detect and contain breaches quickly. They have a Security Operations Center and 24/7 monitoring, after all.
The consequence: Breaches persist for months. The Conduent attack ran from October 21, 2024, through approximately January 13, 2025, nearly three months of unauthorized access. During that time, attackers exfiltrated roughly 8.5 terabytes of data. This suggests either detection controls failed or alerting thresholds were set too high.
The fix: Require vendors to provide detection metrics specific to your data. How quickly do they detect unauthorized access attempts to systems processing your data? What's their mean time to containment for confirmed incidents? What triggers an alert when data is exfiltrated? If the vendor can't answer these questions with specific numbers, you have a detection gap. Consider requiring the vendor to implement data loss prevention controls on egress points and to alert you within 24 hours of any suspected unauthorized access to your data.
Mistake 5: Building Incident Response Plans That Assume Internal Breaches
Why it happens: Your incident response procedures focus on breaches of systems you control. You haven't modeled scenarios where a processor is breached and you need to assess impact without direct access to forensic evidence.
The consequence: When the vendor notifies you of a breach, you can't quickly determine which of your data subjects are affected, what data was compromised, or whether you have a 72-hour notification obligation to your supervisory authority under Article 33 GDPR. The Conduent breach affected 62.2 million people across multiple client organizations. Each controller had to independently assess notification obligations without full visibility into the vendor's systems.
The fix: Build a processor breach playbook that addresses how you'll obtain forensic details from the vendor, identify affected data subjects in your systems, assess notification thresholds when you don't control the evidence, and who has authority to make notification decisions on compressed timelines. Test this playbook annually with a tabletop exercise that simulates a vendor breach scenario. Document your vendor's breach notification timeline in your processing agreement, 24 hours is reasonable; 30 days is not.
Prevention Checklist
Run this checklist quarterly for each processor handling sensitive personal data:
- Validate vendor's encryption controls (at rest and in transit) within the last 90 days
- Confirm your data is logically segregated from other clients' data
- Verify backup retention periods align with your retention rules
- Review vendor's detection metrics for unauthorized access to your data
- Test your ability to identify affected data subjects if the vendor reports a breach
- Confirm data location complies with any transfer restrictions you're subject to
- Document the specific data elements the vendor processes and verify they're limited to operational necessity
- Review vendor's sub-processor list and confirm each has equivalent security controls
- Verify your contract grants audit rights and you've exercised them in the past 12 months
The Conduent breach wasn't caused by sophisticated zero-day exploits. It resulted from operational gaps common in third-party breaches: too much data shared, insufficient ongoing validation, and detection controls that failed to catch a three-month intrusion. Fix these mistakes, and you significantly reduce the likelihood that your vendor becomes your breach notification.
