When Conduent disclosed that attackers accessed systems containing information on approximately 25 million individuals, the company reported about $25 million in breach-response costs. But the real cost isn't just in Conduent's incident response budget. It's in the hundreds of organizations now facing regulatory notifications, customer communications, and operational disruption because they outsourced critical processes to a vendor whose security posture they didn't fully understand.
The Conduent breach isn't an outlier; it's a pattern. This pattern reveals a discomforting truth: most vendor risk management programs are designed to satisfy audit requirements, not to prevent incidents.
Why These Mistakes Keep Happening
Organizations build vendor risk programs around static assessments because that's what auditors ask for: annual questionnaires, SOC 2 reports, and contractual language about security standards. These artifacts create the appearance of oversight without delivering the visibility you actually need.
The problem worsens when vendor risk management is split across multiple functions. Procurement owns the contract, IT reviews technical controls, Legal negotiates indemnification clauses, and Compliance tracks regulatory requirements. No single team has end-to-end accountability for understanding what happens when the vendor fails.
Meanwhile, your vendor environment keeps changing. The service provider updates its infrastructure, acquires another company, expands into new jurisdictions, or hires a subcontractor you've never heard of. Your risk posture shifts, but your oversight program stays frozen at the moment you completed the initial assessment.
Mistake 1: Treating Due Diligence as a One-Time Event
You conduct a thorough assessment before signing the contract. The vendor completes a detailed questionnaire, provides SOC 2 attestations, and you review their security policies. Everything looks acceptable, so you approve the relationship.
Then nothing happens for twelve months.
Why it happens: Organizations design vendor onboarding processes, not vendor oversight processes. Once the contract is signed and the service goes live, the vendor disappears from active monitoring unless someone raises a concern.
The real consequence: When Conduent systems were compromised in early 2026, many affected organizations had conducted initial due diligence years earlier. The security posture they evaluated during onboarding bore little resemblance to the actual risk environment at the time of the breach.
The specific fix: Implement continuous monitoring triggers tied to material changes in vendor risk profiles. Define what constitutes a material change (leadership turnover, merger activity, regulatory action, security incidents at peer organizations, changes in financial stability) and establish automated alerts when those conditions occur. Your vendor risk register should include a last-reviewed date for every critical vendor, with mandatory reassessment intervals based on the sensitivity of data they handle.
Mistake 2: Relying on Vendor-Provided Documentation Without Independent Verification
Your vendor sends you their SOC 2 Type II report. It's 200 pages long and includes clean opinions from a reputable auditor. You file it in your vendor documentation folder and consider the security review complete.
Why it happens: Reading and interpreting third-party attestation reports requires specialized expertise. Most organizations lack the internal resources to analyze these documents critically, so they treat the existence of the report as proof of adequate controls.
The real consequence: SOC 2 reports describe controls at a specific point in time, evaluated against criteria the vendor selected. They don't tell you whether those controls address your specific risk concerns, whether they've remained effective since the audit period ended, or whether the vendor operates other systems outside the audit scope that handle your data.
The specific fix: Develop a standardized evaluation framework that maps your specific risk requirements to vendor-provided documentation. When you receive a SOC 2 report, identify which of your critical data flows are covered by the audited environment and which fall outside the scope. For high-risk vendors, supplement attestation reports with direct evidence: request screenshots of access logs, copies of recent vulnerability scan results, or documentation of how they responded to the last security incident. If the vendor handles sensitive personal data or supports critical operations, consider negotiating audit rights that allow your team or a third-party assessor to conduct independent reviews.
Mistake 3: Ignoring Fourth-Party Risk
You carefully vet your direct vendor relationships. You review their security controls, evaluate their compliance posture, and monitor their performance. But you don't ask who they rely on to deliver the services you've contracted for.
Why it happens: Contractual relationships create a false boundary around risk oversight. Organizations assume that if they've established adequate controls over their direct vendors, they've addressed the risk. They don't recognize that their vendors are building their own vendor ecosystems, creating layers of risk exposure that extend far beyond the primary relationship.
The real consequence: When a vendor's subcontractor experiences a security incident, the impact propagates back through the supply chain to your organization. You may not even know the subcontractor exists until you're managing the fallout from their failure.
The specific fix: Require vendors to disclose material subcontractor relationships as part of the initial due diligence process and update that disclosure whenever they add new subcontractors who will access your data or support critical services. For high-risk vendors, include contractual language that requires them to impose the same security and privacy standards on their subcontractors that you've imposed on them. Maintain a fourth-party Risk Portfolio that documents which subcontractors support which services, and establish notification requirements that trigger when vendors change their subcontractor relationships.
Mistake 4: Treating All Vendors the Same
Your vendor risk program applies the same assessment process to every third-party relationship, regardless of what data they access or what services they provide. The company that hosts your marketing website goes through the same review as the provider that processes employee health records.
Why it happens: Standardized processes are easier to administer than risk-based approaches. Many organizations build vendor risk programs around a single questionnaire template and assessment workflow because it's simpler than maintaining multiple evaluation tracks.
The real consequence: You spend significant resources reviewing low-risk vendors while high-risk relationships receive inadequate scrutiny. When an incident occurs at a critical vendor, you discover that the assessment you conducted didn't address the controls that actually mattered.
The specific fix: Implement a vendor tiering system that classifies third parties based on the sensitivity of data they access, the criticality of services they provide, and the regulatory obligations they help you meet. Define different assessment requirements for each tier. Low-risk vendors might complete a basic questionnaire. High-risk vendors should undergo detailed security reviews, provide evidence of control effectiveness, and submit to periodic reassessment. Document your tiering methodology and apply it consistently across all vendor relationships.
Mistake 5: Assuming Contractual Language Transfers Risk
Your vendor contracts include detailed security requirements, breach notification obligations, and indemnification clauses. You believe these provisions protect your organization if something goes wrong.
Why it happens: Legal teams focus on allocating liability through contractual language. While important, these provisions create a false sense of security that can reduce the urgency around operational oversight.
The real consequence: When a vendor breach occurs, contractual protections rarely eliminate your organization's exposure. You still face regulatory notification requirements, customer communications, operational disruption, and reputational damage. The indemnification clause might eventually recover some costs, but it won't prevent the incident or eliminate the immediate consequences.
The specific fix: Treat contracts as one component of vendor risk management, not a substitute for operational oversight. Use contractual language to establish clear expectations around security standards, incident response procedures, and audit rights, but recognize that preventing incidents requires ongoing monitoring and active oversight. Focus your energy on building relationships with vendors that demonstrate consistent security practices, not on negotiating stronger indemnification language with vendors whose practices concern you.
Prevention Checklist
Build a vendor risk program that actually prevents incidents:
Before onboarding:
- Classify the vendor relationship based on data sensitivity and service criticality
- Define specific security requirements tied to your risk tier
- Request evidence of control effectiveness, not just policy documentation
- Identify fourth-party relationships that will access your data
- Establish clear incident notification requirements with specific timeframes
During the relationship:
- Set mandatory reassessment intervals based on vendor risk tier
- Monitor for material changes in vendor risk profile
- Track vendor security incidents and regulatory actions
- Maintain current documentation of what data the vendor accesses
- Review vendor SOC 2 reports for scope limitations and exceptions
When incidents occur:
- Activate your incident response structure immediately
- Document the timeline of vendor notifications
- Assess regulatory notification obligations independently
- Evaluate whether the incident triggers reassessment of other vendors
- Capture lessons learned and update your vendor risk criteria
The Conduent breach exposed information associated with approximately 25 million individuals because organizations trusted a vendor to protect data without maintaining continuous visibility into how that vendor actually operated. Your vendor risk program should assume that trust, by itself, isn't a control.
