Your vendor got breached. Now read your contracts.
You will find indemnification language. You will find security requirement clauses. You will find the carefully worded provisions your legal team insisted on before you shared any data. None of it will protect your brand once there is a breach.
The customers who received notification letters do not distinguish between your breach and your vendor’s breach. The class action plaintiff counsel does not care whose server it was. The regulator investigating the disclosure does not ask which organization’s controls failed first. The damage lands on the name the customer trusted. That name is yours.
This is the supply chain liability problem that secure data collaboration exists to solve. And most organizations are still solving it with paperwork.
The Supply Chain Breach Pattern Is Not Random
Contractual obligations do not change the breach architecture. When you share decrypted data with a third party for processing, that party holds data your customers entrusted to you. If the vendor’s environment falls, that data falls with it. The contract says they are responsible, but the headline says your name.
Red Hat shared credentials through repositories that required decryption for access. The credentials sat readable. Attackers stole them and used them to breach customer infrastructure at hundreds of organizations. That breach was technically a vendor problem. The $100 million in damage belonged to Red Hat. A deeper review of the case is in Red Hat’s $100M Cyber Breach Problem Is Likely Yours Too.
Conduent processed benefits data for government agencies and employers. The data decrypted for processing. ShinyHunters accessed the system and extracted more than 10 million records. The records belonged to people who had never heard of Conduent. Their notification letters came from the agencies and employers they had trusted. Multiple class action lawsuits followed.
The through line in both cases: data that must decrypt to be used becomes data an attacker can easily take.
What the Standard Vendor Security Model Misses
Most security programs focus on access controls: who can reach the data, under what conditions, with what authentication. Those controls determine whether an authorized user gets in. They do not necessarily determine what that user finds when they do, especially if they have any kind of developer or system administrator credentials.
Security questionnaires ask whether vendors encrypt data at rest and in transit. They rarely ask whether vendors encrypt data during processing. That gap is where the breach value lives. At-rest encryption protects the storage layer. It protects nothing the moment an application is in production and processing data.
As we covered in The Encryption At Rest Myth, this is not a vendor-specific problem. It is a fundamental characteristic of how standard encryption deployments work. Every organization sharing data with vendors faces this exposure.
What Secure Data Collaboration Actually Means
Secure data collaboration means data shared with your partners and vendors never exists in a form they can lose. Not just contractually; architecturally. The broader framework for how this works across use cases is in How to Share Sensitive Data Securely. The specific application to vendor relationships works like this:
- The data arrives at your vendor encrypted.
- It stays encrypted during processing.
- The results leave encrypted.
Donoma Seshat delivers this capability today. It deploys at the application layer; your vendor does not replace their infrastructure, and no specialized hardware is required. Seshat runs on standard CPUs. It operates at near-native speed with added latency measured in milliseconds. And it is built for the post-quantum threat environment. An attacker who breaches a Seshat-protected system finds ciphertext with no operational value. There is nothing to ransom, nothing to sell, and no notification obligation triggered because no readable data changed hands.
The More Vendors You Have, the More This Matters
For enterprise teams managing multiple vendor relationships, the value of encryption in use scales with the number of relationships. Every vendor who processes your data unencrypted represents a breach surface you do not control. Every vendor who processes encrypted data represents a breach surface you have neutralized regardless of their security posture.
The math is straightforward. Ten vendor relationships with standard data sharing means ten organizations whose security posture affects your exposure. The same ten relationships with encrypted data sharing means ten breach surfaces that yield nothing usable if they fall.
The cost case for making that shift is in How Much Does a Data Breach Cost? The average is not the relevant number. Your industry average, multiplied by your vendor count, is the relevant number.
Why Seshat Is the Right Approach for This Problem
Not all continuous encryption solutions solve the vendor collaboration problem equally. The architecture matters as much as the concept. Donoma Seshat is purpose-built for enterprise-scale encrypted data collaboration and sovereignty challenges. Four capabilities distinguish it in the market.
- Native speed. Seshat runs at near-native speed with only millisecond latency, so vendor workflows do not change, users perceive no impact and SLAs do not suffer.
- Customized application layer deployment. Seshat sits between the application tier and the data layer. Vendors keep their existing infrastructure. No rip-and-replace. No migration. The integration is additive, not architectural.
- Runs on standard CPU architecture. Competing continuous encryption platforms require specialized GPU or FPGA hardware, adding significant infrastructure cost before a single query runs on encrypted data. Seshat runs on the hardware your vendors already own.
- Post-quantum ready. Seshat’s encryption architecture addresses the post-quantum threat environment. The vendor relationships you are protecting today need to stay protected as the cryptographic landscape changes.
These are not feature comparisons for a procurement checklist. They are the reasons Seshat is operationally deployable in vendor environments today.
The Legal Framing Is Shifting
Courts are beginning to ask whether organizations shared decrypted data with vendors when continuous encryption technology was available and deployable. Claiming vendor liability becomes a harder defense when plaintiff counsel can show the technology existed to prevent the exposure entirely.
The question worth asking before your next vendor data sharing agreement is not what the contract says. It is what the vendor would find if their systems were accessed during processing. If the answer is your data in readable form, the contract is not your protection. The architecture is.
The technology is ready. The business case is clear. The time for action is now.
If you want to see how Donoma Seshat protects data across your vendor relationships; book a solution briefing with the Donoma team today.
Frequently Asked Questions
What is secure data collaboration and why does it matter for enterprise vendor relationships?
Secure data collaboration means enabling partners, vendors, and internal teams to work with sensitive data without that data ever existing in a form they can lose or expose. It matters for vendor relationships because the standard model requires vendors to hold decryptable copies of your data to perform their contracted work. When their systems are breached, your data is exposed. Your brand absorbs the damage regardless of what your contract says. Secure data collaboration changes the architecture, so vendors process data that stays encrypted. A breach at their end yields nothing usable.
Why does a vendor breach become the brand’s problem even when the vendor was at fault?
Customers, regulators, and plaintiff counsel do not distinguish between a breach at your organization and a breach at your vendor. The notification letter your customers receive carries your name. The class action complaint names you. The regulatory investigation focuses on the data controller, not the processor. Contractual indemnification may shift financial liability between organizations; it does not protect your brand, your customer relationships, or your regulatory standing.
What is the supply chain breach pattern and which organizations are most at risk?
The supply chain breach pattern occurs when an attacker compromises a vendor or partner with legitimate data access, then uses that access to reach the underlying data or downstream systems. Organizations most at risk are those that share sensitive data with multiple third parties for processing: financial institutions sharing customer data with analytics vendors, healthcare organizations sharing patient data with technology partners, enterprises sharing intellectual property with supply chain partners. The more third parties hold decryptable copies of your data, the larger the breach surface you do not control.
How does continuous encryption eliminate supply chain breach exposure?
Continuous encryption keeps data encrypted during active processing, not just at rest and in transit. When your vendor processes encrypted data, they never hold a decryptable copy, nor access cleartext data. Their application runs queries and returns results. The underlying data stays encrypted throughout. A breach at the vendor yields ciphertext with no operational value. There is nothing to ransom, nothing to sell, and no notification obligation triggered because no readable data changed hands.
Does requiring vendors to use continuous encryption create integration complexity?
No. Continuous encryption deploys at the application layer without requiring vendors to replace their infrastructure. The encryption sits between their application and the data. Their systems run as they always have. What changes is what sits at the data layer. Vendors do not need to change their processes or retrain their teams. The protection is architectural, not procedural.
What is the emerging legal standard for data shared with vendors and third parties?
Courts are beginning to examine whether organizations shared decrypted data with vendors when continuous encryption technology was available and deployable. The question plaintiff counsel now asks is not just whether the breach occurred at a vendor, but whether the organization sharing the data took available steps to ensure that vendor could not lose readable data. Contractual indemnification is a harder defense when the technology to prevent the exposure existed and was not implemented.
Additional Reading:
How to Share Sensitive Data Securely
Why Encrypted Data Gets Stolen: The Conduent Breach
