Table of Contents
Why Supplier Risk Is Now the Primary Breach Vector
The most damaging breaches of the past several years did not begin with an attacker breaking through the victim’s own perimeter. SolarWinds, Kaseya, MOVEit, 3CX – each arrived through the supply chain: a trusted vendor, a software update, a file-transfer product, a service provider with standing access. The economics are simple from the attacker’s perspective. Compromising one widely used supplier yields access to hundreds or thousands of downstream organizations, each of which has already granted that supplier some combination of network access, data access, and implicit trust.
Meanwhile, the average enterprise’s supplier ecosystem keeps growing – cloud services, SaaS tools, outsourced development, logistics providers, payroll processors, marketing platforms – far faster than most security teams’ capacity to evaluate them. The result is a widening gap between the suppliers an organization depends on and the suppliers it has actually assessed. Every supplier in that gap is an open question in the organization’s risk picture, and increasingly, a question regulators expect to see answered.
What Is Supplier Risk Management?
Supplier risk management also called third-party risk management (TPRM) or vendor risk management, is the structured discipline of identifying every external party that could affect your organization’s security posture, evaluating the risk each one introduces, imposing security requirements proportionate to that risk, and monitoring the relationship continuously for as long as it lasts.
A mature program answers five questions at any moment, with evidence:
- Who are our suppliers? A complete, current register – including the “shadow vendors” adopted by business units without procurement’s involvement.
- Which of them matter most? A risk classification that concentrates assessment effort where data access, system access, and business impact are highest.
- What is their actual security posture? Assessment responses that have been scored and challenged, not merely collected and filed.
- What do we require of them? Documented cyber requirements – contractual and technical – matched to each supplier’s risk tier, with gaps tracked to closure.
- What has changed since we last looked? Continuous monitoring, including external attack-surface scanning, because a supplier’s posture on the day it answered a questionnaire says little about its posture eight months later.
What supplier risk management is not is an annual folder of questionnaire PDFs. Collecting self-attestations without classification, validation, requirement enforcement, or monitoring is compliance theater – it produces paper, not risk reduction.
The Regulatory Mandate: NIS2, ISO 27001, BoI 361, Privacy Law, DORA
Supplier risk management has moved from good practice to explicit legal and regulatory requirement across every framework relevant to Israeli and EU-exposed enterprises:
| Framework | Supplier risk requirement | What evidence is expected |
|---|---|---|
| NIS2 – Article 21 | Supply chain security is a mandatory risk-management measure for essential and important entities, including security-related aspects of relationships with direct suppliers | Documented supplier security policy, supplier assessments, and measures proportionate to supplier risk |
| ISO 27001:2022 – Annex A 5.19–5.22 | Four dedicated controls: supplier relationship security, addressing security in supplier agreements, managing ICT supply chain security, and monitoring/review of supplier services | Supplier security policy, contractual security clauses, supplier register, evidence of ongoing monitoring |
| Bank of Israel Directive 361 | Regulated banking institutions must assess and manage the risk of external service providers, including contractual security requirements, ongoing oversight, and contingency planning | Provider risk assessments, contract provisions, monitoring records, exit/contingency plans |
| Israeli Privacy Protection Law | Controllers must conduct due diligence over data processors and bind them with data-processing agreements; processor oversight is an ongoing duty, sharply reinforced by Amendment 13’s expanded enforcement powers | Processor inventory, DPAs, due-diligence records, periodic review evidence |
| DORA – Chapter V | EU financial entities must maintain a register of ICT third-party providers, conduct pre-contract due diligence, embed minimum contractual provisions, monitor continuously, and plan exit strategies | ICT third-party register, due-diligence files, contract clause coverage, monitoring and exit documentation |
Two practical implications follow. First, an organization subject to more than one of these frameworks should run one supplier risk program that produces evidence mapped to all of them – not one program per framework. Second, cyber insurers have converged on the same expectations: vendor risk questions now appear on effectively every meaningful cyber policy application, and weak answers translate directly into worse terms or declined coverage.
Stage 1: Supplier Mapping – You Cannot Manage What You Have Not Found
Every working program begins with discovery, and discovery consistently surprises. Organizations that estimate “maybe 60 or 70 suppliers” routinely map 150 or more once all the sources are consulted: procurement records, accounts payable, contract repositories, cloud and SaaS spend reports, IT asset inventories, and interviews with business unit owners. The gap is dominated by shadow vendors – tools and services adopted directly by marketing, HR, engineering, or finance without a security review.
The output of this stage is a master supplier register: one structured record per supplier capturing what the supplier does, what data it can access, what systems it connects to, who owns the relationship internally, what contract governs it and when it expires, and what certifications the supplier claims. The register is the foundation everything else builds on – tiering, assessment scheduling, contract review, monitoring, and the audit evidence trail. It must live in a system that keeps it current (IPV Security clients run it in the CISOteria Supply Chain module), because a register maintained in a spreadsheet is stale within a quarter.
Stage 2: Risk Tiering – Not Every Supplier Deserves the Same Effort
Assessing 150 suppliers with equal depth is neither possible nor sensible. Risk tiering solves the resource problem by classifying every supplier – typically into four tiers: Critical, High, Medium, Low – using objective scoring dimensions rather than gut feel:
- Data access – does the supplier store or process personal data, financial data, intellectual property, or regulated data?
- System access – does the supplier hold credentials, network connectivity, API access, or physical access to your environment?
- Business continuity impact – if this supplier failed tomorrow, how quickly and how badly would operations degrade?
- Substitutability – how difficult would replacement be?
- Regulatory classification – is the supplier a data processor under privacy law, an ICT provider under DORA, or a material outsourcing arrangement under BoI 361?
The tier then drives everything: assessment depth (a critical supplier warrants a deep-dive assessment with evidence review; a low-risk supplier warrants lightweight registration), reassessment frequency, contractual requirements, and monitoring intensity. Tiering is what turns supplier risk from an unbounded task into a managed program – effort flows to where the risk actually sits.
Stage 3: Questionnaires That Work – Tiered, Chased, and Validated
The security questionnaire is the workhorse of supplier assessment – and the place where most programs quietly fail. Three disciplines separate questionnaires that reduce risk from questionnaires that generate shelf-ware:
Tiered questionnaires. A 300-question form sent to every supplier guarantees low response rates and low-quality answers. Risk-proportionate questionnaires – deep for critical suppliers, focused for medium ones, minimal for low-tier registration – respect both sides’ time and produce dramatically better data. Language matters too: in the Israeli market, questionnaires sent in Hebrew achieve significantly higher and faster response rates from local vendors than English forms.
Managed follow-up. Suppliers do not answer questionnaires spontaneously. A working program has a defined outreach and escalation protocol – reminders on a schedule, escalation to the internal relationship owner, and a documented risk treatment for persistent non-responders. For a critical supplier, non-response is itself a high-risk finding that belongs in the risk register, not an awkward blank to ignore.
Validation, not collection. An unread “yes” is worth nothing. Every response from higher-tier suppliers should be scored, challenged where answers are implausible or internally inconsistent, and backed by evidence requests – certificates, audit reports, policy documents, configuration attestations. The difference between collecting answers and verifying them is the difference between a program that would survive an auditor’s sampling and one that would not.
Stage 4: Directing Suppliers to the Right Requirements
Assessment without consequence changes nothing. The fourth stage converts findings into obligations: each supplier receives the cyber requirements that match its tier – a requirements pack covering the technical controls expected of it, the contractual security clauses its agreement must contain (audit rights, breach notification timelines, data-processing terms, sub-contractor controls, insurance minimums), and the specific remediation items arising from its assessment.
Two practices make this stage effective. First, contract review: existing supplier agreements are checked against the security clause baseline, and gaps are queued for renewal negotiations – because a requirement that exists only in an email has no force. Second, tracked remediation: every gap becomes a remediation item with an owner and a due date, tracked to closure in the same system as the register. Suppliers implement the fixes in their own environments; your program’s job is to direct, track, and verify – and to escalate to the business owner when a critical supplier will not move.
Stage 5: Continuous External Attack-Surface Scanning
A questionnaire describes a supplier’s posture on the day it was answered. Suppliers deploy new systems, let certificates lapse, expose services to the internet, and suffer incidents between assessment cycles – which is why mature programs add continuous external attack-surface scanning of suppliers’ internet-facing assets.
External scanning is non-intrusive: it observes what any attacker can observe – exposed services and ports, expired or misconfigured TLS certificates, vulnerable software versions visible from the outside, leaked credentials appearing in breach corpora, and domain or mail-security misconfigurations. Run on a regular cadence across the supplier portfolio, it does two things a questionnaire never can: it provides an independent, evidence-based check on self-reported answers, and it surfaces changes – a new exposure at a critical supplier shows up in your dashboard within days, not at next year’s reassessment or, worse, in the news. Scan findings feed back into the supplier’s risk score and remediation queue, closing the loop between monitoring and action.
How IPV Security Approaches Supplier Risk Management
IPV Security delivers supplier risk management as a managed program, not a software license. IPV analysts perform the mapping, run the tiering workshops, distribute and chase the questionnaires in Hebrew or English, validate responses against evidence, prepare the requirement packs and contract clause reviews, and operate the continuous external scanning – while the client retains decision authority and full visibility.
The program runs on the CISOteria Supply Chain module: the master supplier register, tier classifications, questionnaire distribution and response tracking, evidence vault, external scan findings, expiry alerts, and the supplier risk heatmap all live in one platform, integrated with the client’s main risk register. Because the platform stays current between engagement cycles, the program produces something most organizations have never had: supplier-risk evidence that is audit-ready on any given day – for an ISO 27001 auditor, a NIS2 supervisor, a Bank of Israel examiner, or a cyber insurer – without a pre-audit scramble. Within the IPV methodology, the service delivers the ASSESS and COMPLY pillars across the supply chain.
Engagements start as a 4-6 week program build (policy, mapping, tiering) and extend to a full program or an ongoing managed service with quarterly reassessments, 10-business-day onboarding of new suppliers, and monthly executive reporting.
About the Author
Ido Ganor is the Founder and CEO of IPV Security, an Israeli enterprise cybersecurity advisory firm serving mid-market companies across Israel and the EU. He brings 21+ years of enterprise CISO experience across regulated industries including financial services, critical infrastructure, and technology. He is the creator of the CISOteria Cyber OS™ platform and the architect of IPV Security’s 4-Pillar Operating Model for managed security leadership.
Related Articles
- Compliance Guide: ISO 27001, NIS2, DORA, and GDPR Explained →
- Which Cyber Regulations Apply to You? Applicability, Ransomware Readiness & Architecture →
- What Is the CISOteria Platform? →
Is your weakest supplier your biggest risk? IPV Security maps, tiers, assesses, and continuously scans your entire supplier ecosystem – a fully managed program on the CISOteria Supply Chain module, producing evidence that satisfies NIS2, ISO 27001, BoI 361, and Privacy Law requirements year-round.
Frequently Asked Questions
What is the difference between supplier risk management and just sending vendor questionnaires?
A questionnaire is one instrument inside one stage of a five-stage program. On its own it tells you what a supplier says about itself, once, with no classification to decide who should be asked what, no validation to test whether the answers are true, no requirement enforcement to change anything, and no monitoring to detect drift. A supplier risk management program wraps the questionnaire in the machinery that makes it meaningful: a complete supplier register, risk tiering that calibrates assessment depth, scored and evidence-backed validation, tier-matched cyber requirements tracked to closure, and continuous external scanning between cycles. Auditors and regulators increasingly probe exactly this distinction – NIS2 and BoI 361 examiners ask to see the program operating, not the folder of PDFs.
How many suppliers do we need before a formal program is worth it?
Fewer than most organizations assume. The trigger is not supplier count but concentration of risk: one payroll processor, one managed IT provider, or one cloud platform with deep access can carry more risk than fifty stationery vendors. As a rule of thumb, an organization with 30 or more suppliers – or any supplier holding privileged access to systems or regulated data – has enough exposure to justify structured mapping and tiering. A foundation-level program (policy, full mapping, tiering of the top 30 suppliers) typically takes four to six weeks, which is a modest investment against the cost of a single significant vendor incident.
What is a supplier risk tier, and how is it decided?
A tier is a classification – typically Critical, High, Medium, or Low – that determines how deeply a supplier is assessed, how often it is reassessed, what contractual requirements apply to it, and how intensively it is monitored. Tiers are assigned by scoring objective dimensions: what data the supplier can access, what systems it can reach, how badly its failure would disrupt operations, how easily it could be replaced, and whether it carries a regulatory classification such as data processor or material outsourcing provider. The scoring must be documented and repeatable – regulators reviewing a supplier risk program routinely ask why a given supplier sits in a given tier, and “judgment call” is not an acceptable answer.
Do NIS2 and ISO 27001 really require us to manage supplier risk, or is it optional?
It is required. NIS2 Article 21 lists supply chain security among the risk-management measures that essential and important entities must implement, explicitly including the security aspects of relationships with direct suppliers. ISO 27001:2022 devotes four Annex A controls to the topic – 5.19 (information security in supplier relationships), 5.20 (addressing security within supplier agreements), 5.21 (managing security in the ICT supply chain), and 5.22 (monitoring, review, and change management of supplier services) – and a certification audit will sample the evidence behind each. Bank of Israel Directive 361 imposes parallel duties on regulated banking institutions, and the Israeli Privacy Protection Law requires due diligence and data-processing agreements for processors. An organization subject to any of these frameworks needs a demonstrable program, not an intention.
What does continuous external scanning of suppliers actually detect?
External attack-surface scanning observes suppliers’ internet-facing assets the way an attacker would – without credentials and without touching internal systems. In practice it detects exposed services and management interfaces, expired or weak TLS certificates, outdated software versions with known vulnerabilities visible from the outside, email security misconfigurations (SPF/DKIM/DMARC), subdomain and DNS hygiene issues, and credentials associated with the supplier’s domains appearing in public breach data. Its value is independence and freshness: it verifies self-reported questionnaire answers against observable reality, and it detects deterioration within days rather than at the next annual assessment. It does not replace a penetration test – it is breadth and continuity, not depth.
Can we outsource the whole supplier risk program?
Yes and for most mid-market organizations it is the only realistic way to run one properly. An internal program requires dedicated GRC capacity, questionnaire tooling, assessment expertise, and sustained follow-through; it is usually the first thing dropped when the security team is stretched. In a managed model, IPV Security owns the process end-to-end – mapping, tiering, questionnaire cycles, validation, requirement packs, external scanning, and reporting – on the CISOteria Supply Chain module, while the client’s team reviews the dashboard, makes the risk decisions, and presents audit-ready evidence when regulators, auditors, or insurers ask. Decision authority stays with the organization; the operational burden does not.