This information first appeared in a video on Help Net Security
Recent high-profile incidents involving Oracle and Halo serve as crucial reminders that your security is only as strong as your weakest vendor. When the software and services you depend on daily experience security incidents, the ripple effects can hit your organization almost immediately — often before you even receive a notification email.
As someone who's managed security programs and vendor relationships, I've seen firsthand how challenging third-party risk can be. But here's the reality we all need to accept: you can't prevent vendor breaches, but you absolutely can reduce their impact on your business.
Let's start with an uncomfortable but necessary reality check: you can never truly offload risk to third parties. You can manage risk, you can have vendors help you manage risk, and you can even contract people to help you manage risk — but at the end of the day, the risk inherently stays within your business.
Even with the best contracts and legal teams, if a vendor breach leads to your data being compromised or your operations disrupted, those consequences still affect your organization. Legal remedies might ease the financial pain afterward… but they can't undo the operational damage or reputational impact.
This is why taking a "set-it-and-forget-it" approach to vendor security is so dangerous. The threat landscape evolves constantly, and yesterday's secure vendor could be tomorrow's security headline.
When it comes to vendor incidents, you'll typically encounter one of two scenarios:
While these scenarios feel very different from a relationship perspective, your internal response needs to be equally robust for both. That's where preparation becomes invaluable.
As with most security, preparation starts with a comprehensive review: document all your vendors, especially those with access to your systems or data. This inventory should answer basic questions about what services each vendor provides, what data they access or store, what systems they connect to, and what level of access they have. This inventory becomes your foundation for everything that follows, giving you visibility into your extended attack surface.
Build this assessment into the process of choosing future vendors by incorporating security questions into your selection and onboarding process. This doesn't have to be an overwhelming 300-question assessment that no one reads, just focus on what matters most to your organization: How do they secure customer data? What's their incident response process? How quickly do they notify customers of security incidents? What encryption and access controls do they use? The goal isn't just compliance — it's understanding how their security posture might affect yours. You may also want to search discussions by current/former customers to get at least an additional perspective on how well the vendor meets the standards set in their responses.
Headlines about vendor breaches can be very important even if they don't affect your organization, by presenting opportunities to model if a similar incident affected a vendor you do use. For each critical vendor, model out scenarios: What happens if this vendor experiences a data breach? How would we quickly revoke their access to our systems? What data might be at risk, and how can we limit exposure? How would we respond if the vendor was unavailable? What would happen if the vendor closed their doors tomorrow? Develop step-by-step response playbooks that your team can follow, even in high-stress situations. Include contact information for vendor security teams and specific actions your internal teams should take. And then (this is an important step that is often missed) – run through these playbooks as a tabletop exercise with the team members responsible for each role. These playbooks prove invaluable both when vendors proactively notify you of incidents and when you need to take precautionary measures based on unconfirmed reports.
Security isn't static, and neither should your vendor risk management be. Establish a scheduled cadence for reviewing your vendors' security posture: annually for critical vendors, during contract renewals, after significant changes to their service or infrastructure, and following security incidents. During these reviews, reassess whether the vendor's current security controls still align with your risk tolerance and whether any access permissions need adjustment. This regular maintenance helps ensure your vendor relationships evolve alongside changing security requirements and business needs.
This is a simple but powerful step: ensure your contracts include language that requires prompt notification of security incidents. Specify how quickly they must notify you (24-48 hours is common), what information they must provide, and what assistance they must offer for your investigation. Many vendors already have standard terms for this, but don't assume — verify the language meets your needs and negotiate if necessary. Having these requirements contractually defined gives you leverage when timing matters most.
The connected nature of modern business means vendor risk management isn't optional — it's essential. But approaching it pragmatically can make a significant difference when incidents occur.
I've seen organizations weather vendor breaches with minimal disruption because they had clear visibility into their vendor relationships and pre-defined response plans. I've also seen the opposite: organizations thrown into chaos when a critical vendor experienced an incident, and no one knew exactly what systems or data might be affected.
The difference wasn't resources or sophistication — it was preparation and acknowledging that vendor risk remains your responsibility to manage.
By taking these practical steps, you can't prevent your vendors from experiencing security incidents, but you can absolutely limit how much those incidents impact your business. And in today's interconnected world, that resilience might be the most valuable security control you can build.