Understanding Third-Party Cyber Risk for SMBs
In September 2024, Jaguar Land Rover suffered a crippling cyberattack that temporarily halted operations. The incident was serious enough on its own, but the real story emerged when the ripple effects became visible. Over five thousand companies felt the impact of JLR's downtime, many of them small suppliers who collectively lost an estimated £1.9 billion. These suppliers weren't hacked. They weren't the target of the attack. They couldn't operate because their customer had gone dark.
Introduction
In this article, I will discuss two topics. The first one is a dimension of cyber risk that rarely gets mentioned in SMB circles, yet it represents one of the most significant operational exposures many businesses face. When we talk about cybersecurity for small and medium enterprises, the conversation typically centers on preventing direct attacks against our own systems. Hence, we discuss firewalls, employee training, backup strategies, and incident response plans. These are important, but they only address half of the risk landscape. The other half involves the uncomfortable reality that your business operations depend on vendors, suppliers, and service providers who might fail regardless of how strong your own security posture is.
The second part of this article will delve into a challenge for us SMB owners: most guidance on third-party risk management is written for enterprises with dedicated vendor management teams, comprehensive due diligence processes, and the leverage to demand security assessments from their suppliers. When you're running a business with limited resources, and you're dependent on larger vendors who won't fill out your security questionnaires, the standard advice feels simultaneously overwhelming and impractical. What you need instead is a framework that helps you understand your actual exposure, prioritize your vendor relationships intelligently, and make informed decisions about insurance and business continuity without requiring enterprise-level resources.
The Two Dimensions of Third-Party Risk
Third-party cyber risk manifests in two distinct dimensions that require different responses.
The first is the security and compliance dimension. This involves understanding what data your vendors have access to, what security controls they maintain, what contractual protections you have, and how you would respond if they experienced a breach that exposed your customer data or intellectual property. This is the dimension that compliance frameworks like ISO 27001, NIS2, and DORA address through vendor assessment requirements, contract provisions, and ongoing monitoring obligations.
The second dimension is financial risk transfer through insurance products. This addresses a different question entirely: what happens when a vendor's failure prevents you from operating, even temporarily? If your payment processor goes down for three days, you can't process customer transactions regardless of how secure your own systems are. If your cloud hosting provider experiences an outage — as recently happened with Cloudflare — your SaaS product isn't available to customers even though you did nothing wrong. If your primary component supplier gets hit with ransomware and can't fulfill orders, your manufacturing line stops. These scenarios create business interruption losses that your standard cyber insurance policy may not cover because the incident didn't happen to you directly.
Cloudflare Outage
The message users see when attempting to access your application.
Most SMBs focus exclusively on the first dimension because that's where compliance requirements and security best-practice literature point them. The insurance dimension gets less attention, partly because many business owners don't realize these products exist and partly because insurance conversations tend to happen separately from security and risk management discussions. But for resource-constrained organizations, understanding both dimensions and how they work together is essential for building practical resilience.
Understanding Contingent Business Interruption Coverage
Standard cyber insurance policies typically cover your direct losses when you're the victim of a cyberattack or systems failure. They pay for forensic investigations, legal fees, notification costs, regulatory fines, and your own business interruption losses while you recover. What they often don't automatically include is coverage for business interruption caused by incidents at your vendors or suppliers. This is where contingent business interruption coverage comes in.
Contingent business interruption coverage is designed specifically for scenarios where you can't operate because someone else in your business ecosystem has experienced a cyber incident or systems failure. The key insight is that the triggering event doesn't have to be a security incident in the traditional sense. An unintentional systems outage at a critical vendor triggers this coverage just as much as a ransomware attack would. The coverage focuses on the business interruption impact to you rather than the cause of the incident at the vendor.
The challenge is that many SMB owners don't realize this coverage exists as a separate component that may need to be explicitly added to their cyber insurance policy. They assume their cyber insurance covers all scenarios where technology failures disrupt their business, but that assumption is often wrong. This creates a silent gap in their risk management strategy where they've invested in security controls and purchased insurance, but still have significant uninsured exposure to vendor failures.
When you're evaluating whether you need this coverage and at what limits, you need to understand which vendor failures would actually create material business interruption losses for your organization. This is where the business impact analysis framework becomes essential, because it helps you move from abstract vendor risk to concrete financial exposure.
You can read more about this here.
Simplified Business Impact Analysis
Enterprise business impact analysis frameworks are comprehensive but often overwhelming for SMBs. They involve mapping every business process, calculating precise recovery time objectives, estimating financial impacts with actuarial precision, and maintaining detailed documentation that requires dedicated resources to keep current. However, what SMB owners often need is something simpler that still provides enough insight to make intelligent decisions about vendor risk priorities and insurance coverage.
Identifying Key Business Processes
The simplified approach starts by identifying your core business processes. These are not every process your organization performs, but specifically the ones that directly generate revenue or fulfill your core value proposition to customers. For a SaaS company, this might include customer acquisition, product delivery, customer support, and billing. For a professional services firm, it might be project delivery, client communication, invoicing, and knowledge management. For a manufacturer, it could be order intake, production, quality control, logistics, and customer service. The key here is to limit yourself to five to seven core processes at most, because you want this exercise to be completed in a few hours rather than become a months-long documentation project.
For each core process you've identified, you need to answer two fundamental questions.
First, how long could this process go on before you start experiencing significant harm to your business? This doesn't require precision down to the hour. Categories like "hours," "one to two days," "three to five days," or "a week or more" are sufficient for this exercise. What you're establishing is a practical understanding of time sensitivity. Some processes are so critical that even a few hours of downtime creates significant problems. Others might be inconvenient if down for a day, but only become serious business issues after several days.
The second question is what would actually happen if this process stopped for that length of time. Think concretely about the consequences in terms of lost revenue, customer churn, contractual penalties, regulatory fines, reputational damage, or additional costs you'd incur trying to work around the outage. Again, rough magnitude is more valuable than false precision. Understanding that a particular outage would cost you thousands, tens of thousands, or hundreds of thousands of euros is sufficient to prioritize your risk management efforts appropriately.
You can download a ready-to-use BIA template here.
Connecting the Dots
Once you understand your critical processes and their time sensitivity, you trace each one back to its dependencies. For each critical process, identify which vendors, suppliers, or service providers would cause that process to fail if they experienced an outage. This is where abstract vendor risk becomes concrete operational exposure. Your ability to process customer payments depends on your payment processor. Your product delivery depends on your cloud infrastructure provider. Your customer support depends on your helpdesk platform. Your manufacturing depends on specific component suppliers. Your professional services delivery might depend on collaboration platforms or specialized software tools.
The insight that often emerges from this exercise is the discovery of single points of failure you hadn't fully appreciated. You might realize that one SaaS vendor supports three core processes, so an outage would cascade across your entire operation. You might discover that you have no practical backup for a critical service because you've optimized for cost or convenience rather than resilience. You might find that your most time-sensitive processes depend on vendors you've never assessed for reliability or business continuity.
This isn't about creating paranoia or suggesting you need redundancy for everything. Resources are limited, and some single points of failure are acceptable risks when the cost of mitigation exceeds the realistic exposure. What this framework provides is informed decision-making about where redundancy matters, where you need contractual protections, where insurance coverage is most valuable, and where your incident response planning needs to focus.
What Good Enough Vendor Management Looks Like for SMBs
The gap between enterprise vendor risk management guidance and SMB reality is substantial. Enterprise frameworks assume you can require security assessments from vendors, that you can walk away from vendors who don't meet your standards, and that you have dedicated teams to monitor vendor performance and compliance. SMBs face different constraints:
You're often dependent on large SaaS providers that won't complete your security questionnaires.
You may have limited alternatives for critical suppliers.
You're managing vendor relationships as one of many responsibilities rather than as a full-time role.
What good enough looks like in this context starts with focus. Rather than attempting to assess all vendors equally, you concentrate your efforts on the critical dependencies you identified through your business impact analysis. For those vendors, you document what they do, why they're crucial, what data they access, and what alternatives exist if they fail. This documentation doesn't need to be elaborate, but it should be sufficient that someone else in your organization could understand the dependency and begin working on a workaround if needed.
For critical vendors, you ask basic but essential questions even if you can't require comprehensive security assessments:
Do they carry cyber insurance themselves?
What business continuity and disaster recovery capabilities do they maintain?
What are their committed uptime targets, and what remedies are in place if they fail to meet them?
Have they experienced significant outages or security incidents in the past, and how did they handle them?
These questions don't require the vendor to complete lengthy questionnaires, but the answers provide helpful insight into their reliability and how they think about risk.
Your contracts with critical vendors should include provisions that protect your interests when things go wrong. This includes clear service-level agreements with meaningful remedies for failures, liability provisions that don't completely absolve the vendor of responsibility, termination rights that give you an exit if performance degrades, and, ideally, some business continuity commitments about how they'll maintain operations during disruptions. Many SMBs sign vendor contracts without negotiating these terms because they assume they lack leverage. Still, even large vendors will often accept reasonable protective provisions if you ask for them during contract negotiations.
Where you cannot genuinely assess or influence a vendor's practices because of your size or their market position, you shift your focus to your own resilience. This means having documented workarounds or alternatives, even if they're not ideal, maintaining your own backups of critical data rather than relying solely on vendor backup promises, and building operational flexibility that reduces your dependence on any single vendor.
BIA and Insurance Decisions
So, you might wonder, how are these two topics related? The business impact analysis directly informs your insurance coverage decisions in ways that general risk advice cannot. When you've identified that your payment processing going down for three days would cost you fifty thousand euros in lost revenue and potentially cause customer churn, you now have concrete information to evaluate whether contingent business interruption coverage makes financial sense. The insurance premium needs to be weighed against a specific, quantified exposure rather than an abstract fear of vendor failures.
Similarly, when you've mapped your critical vendor dependencies, you can have more intelligent conversations with your insurance broker about what scenarios your policy should cover. If you're primarily concerned about your cloud infrastructure provider, that's a different coverage discussion than if your main exposure is to component suppliers or professional service providers. The policy terms around what constitutes a covered event, what documentation you need to file a claim, and what waiting periods apply all matter more when you understand your actual dependencies.
Your vendor due diligence practices also affect your insurability in ways many SMB owners don't realize. When insurance carriers ask about your vendor management procedures during underwriting, they're assessing whether you understand your critical dependencies and whether you've taken reasonable steps to manage them. They're not expecting enterprise-level vendor assessment programs. Still, they do want to see that you know which vendors matter, that you've asked basic questions about their reliability and business continuity capabilities, that you have some contractual protections in place, and that you've thought about alternatives or workarounds if a critical vendor fails.
This creates a reinforcing cycle where good vendor risk management makes you more insurable at better rates, and the insurance coverage provides financial protection for the residual risk you can't eliminate through vendor management alone. For SMBs operating with constrained resources, this combination of selective vendor management focused on critical dependencies plus appropriate insurance coverage is often more practical than attempting to prevent all possible vendor failures through exhaustive due diligence.
Connecting to Compliance Frameworks
Finally, if you're pursuing ISO 27001 certification, working toward NIS2 compliance, or subject to DORA requirements, your vendor risk management efforts serve double duty. These frameworks all include explicit requirements for managing third-party risks, assessing supplier relationships, and maintaining business continuity capabilities. The simplified BIA framework and vendor management practices we've discussed aren't additional work on top of compliance requirements—they're practical implementations of those requirements that also happen to inform your insurance decisions and improve your actual operational resilience.
ISO 27001 requires supplier relationship management through controls that address supplier security assessment, contract provisions, and ongoing monitoring. The business impact analysis you conduct to understand your critical vendor dependencies directly supports your ISO 27001 business continuity planning requirements. You're creating the same documentation and conducting the same analysis, but applying it to both compliance and insurance risk management purposes.
NIS2 applies to a broader range of organizations and includes specific requirements for identifying critical functions, managing supply chain risk, and ensuring business continuity. The framework for identifying critical business processes and their vendor dependencies addresses these requirements while simultaneously helping you understand where contingent business interruption coverage would be most valuable.
DORA is particularly explicit about third-party risk management for financial entities, requiring ICT third-party risk monitoring, contract provisions, and concentration risk management. The same vendor assessment and dependency mapping that helps you comply with DORA also informs your decisions about insurance coverage and business continuity planning.
The point is that good vendor risk management isn't separate from compliance work. When done thoughtfully, your vendor risk management program simultaneously addresses regulatory requirements, informs insurance decisions, and improves your actual ability to maintain operations when vendors fail. For resource-constrained SMBs, finding these synergies between different risk management objectives is essential for getting meaningful risk reduction without unsustainable resource commitments.
Practical Next Steps
Moving from understanding third-party risk to actually managing it requires concrete actions that fit within your operational constraints.
The first step is conducting the simplified business impact analysis we've discussed. Block out two to three hours, gather the people in your organization who understand your operations, and systematically work through identifying your core business processes, their time sensitivity, and their critical vendor dependencies. Create simple documentation of this analysis—a spreadsheet or table is sufficient—that captures what you've learned about your operational dependencies.
Once you understand your critical vendor dependencies, the second step is reviewing your current cyber insurance policy specifically through the lens of third-party risk. Pull out your policy documents or contact your broker and explicitly ask whether you have contingent business interruption coverage. If you have it, understand what it covers, what limits apply, what documentation would be required to file a claim, and whether any waiting periods apply. If you don't have it, ask your broker to explain what it would cost to add this coverage and at what limits it's available. Come to this conversation armed with the information from your business impact analysis about which vendor failures would create significant business interruption costs.
The third step involves addressing the gaps your analysis revealed. For your most critical vendor dependencies, review the contractual protections in place, the alternatives available if that vendor fails, and whether you need to make changes to reduce your risk. This doesn't mean you need to replace vendors or build redundancy for everything immediately. Still, you should consciously decide which risks you're accepting, which ones you're mitigating, and which ones you're transferring through insurance or contracts.
Finally, incorporate your vendor dependency information into your incident response planning. Make sure the people who would need to respond to a vendor outage know your critical dependencies, have contact information for key vendors, understand available alternatives, and know how to access your insurance coverage if needed. The most complicated incident responses happen when there's a disconnect between who knows about the response plan and who needs to execute it. For SMBs, this often means ensuring that your IT person, your operations leader, and whoever handles insurance and risk management are all working from the same understanding of vendor dependencies and response procedures.
Moving Forward
Third-party cyber risk isn't new, but it's becoming harder to ignore as business ecosystems become more interconnected and dependencies more critical. The JLR incident reminded us that cyber incidents don't respect organizational boundaries, and the financial impact of vendor failures can be just as severe as direct attacks. For SMBs operating with limited resources and significant dependencies on vendors they can't fully control, the combination of focused vendor management, appropriate insurance coverage, and practical business continuity planning provides realistic resilience without requiring enterprise-level programs.
The key is to move from abstract awareness of vendor risk to a concrete understanding of which vendor failures would actually harm your business and what you can do about them. The simplified business impact analysis gives you that concrete understanding. The insurance discussion with your broker provides a financial risk-transfer option for the residual risk you can't eliminate. The vendor management practices we've discussed give you practical ways to reduce risk within your resource constraints. Together, these elements create a vendor risk management approach that's realistic for SMBs while still providing meaningful protection.
Download your ready-to-use BIA template here. If you'd like help conducting a business impact analysis for your organization or reviewing your vendor risk management practices, I'm happy to discuss how we can approach this work in ways that serve both your compliance requirements and your practical business resilience needs.
