What Is External Vendor Risk Assessment?
External vendor risk assessment is the formal process of identifying, analysing, and evaluating the risks that third-party suppliers, vendors, and service providers introduce to your organisation.
Every time you hand something over to an external party — your customer data, your IT infrastructure, your payroll processing, your cloud storage — you take on risk. That vendor's security failures become your problem. Their outages affect your operations. Their compliance gaps can become your regulatory exposure.
A vendor risk assessment is how you understand that risk before it becomes a crisis and manage it throughout the relationship rather than just at the point of signing a contract.
What it covers:
- Cybersecurity controls and data protection practices
- Operational resilience and business continuity
- Financial stability and viability
- Legal and regulatory compliance
- Reputational and ethical considerations
What it is not:
- A one-time contract checklist
- A questionnaire you send and file away
- Something that only applies to your biggest suppliers
- An IT department task that has nothing to do with the business
The reality that underpins all of this: Successive years of breach data from Verizon, IBM, and SecurityScorecard consistently show that a significant and growing proportion of security incidents trace back to a third party rather than to the organisation that suffers the consequences. Most organisations are more exposed through their vendor ecosystem than through their own systems — and the gap is widening, not closing.
Why It Matters
The supply chain attack problem
Attackers have increasingly discovered that it is easier and more rewarding to target a vendor that serves dozens or hundreds of organisations than to attack each target individually. Compromising one vendor can cascade into many victims simultaneously — and the smaller, less-defended vendor is often the path of least resistance into a much larger, better-protected organisation.
This pattern has played out repeatedly in high-profile incidents. CDK Global, a software vendor serving automotive dealerships, was hit by ransomware that simultaneously took down the core operating systems of thousands of dealerships across the country. None of those dealerships had been attacked directly. They were collateral damage from a vendor relationship they had not assessed rigorously enough.
The same logic played out when ION Trading, a financial software vendor, was taken offline — disrupting exchange-traded derivatives operations at some of the world's largest financial institutions, not because those institutions had been breached, but because they depended on a single vendor with a single point of failure.
What both incidents illustrate is not just that supply chain attacks happen, but that their blast radius is determined by how interconnected vendor relationships are and how well organisations have understood their dependencies. Neither point is specific to a year or a particular threat actor. Both are structural features of the modern vendor ecosystem.
The concentration risk problem
Most organisations rely on a small number of cloud providers, identity services, payment processors, and technology platforms. This creates concentration risk — where a problem at one widely shared vendor ripples across an entire industry simultaneously.
The risk cannot be eliminated. But it must be understood and managed. An organisation that cannot answer the question "which vendors, if they failed tomorrow, would stop us from operating?" has not yet done the foundational work of vendor risk management.
The regulatory reality
Vendor risk assessment is no longer just good practice. It is a regulatory requirement across a growing number of frameworks, in every major jurisdiction:
- DORA (Digital Operational Resilience Act) requires EU financial institutions to classify critical technology providers, map dependencies, and maintain vendor risk registers.
- GDPR Article 28 requires documented due diligence on any processor handling personal data.
- ISO 27001 Control A.5.19 requires information security requirements to be agreed with suppliers and assessed.
- NESA / UAE IAS requires vendor and supply chain risk management as part of Information Assurance compliance.
- CBUAE requires banks and payment service providers to assess and monitor the cybersecurity posture of all material technology vendors.
The direction of travel is clear and consistent: regulators everywhere are expanding the compliance perimeter to include supply chain participants, and the expectations around documentation and evidence are tightening, not loosening.
The board has noticed
Vendor risk has moved steadily up the governance hierarchy — from an IT concern, to a compliance concern, to a business concern, to a boardroom concern. This escalation has been driven by the combination of high-profile incidents, regulatory pressure, and the growing recognition that an organisation's resilience is only as strong as its weakest critical dependency.
That shift is durable. Third-party risk is not going to move back down the agenda.
The Five Core Risk Domains
A robust vendor risk assessment evaluates vendors across five core domains. Ignoring any one of them leaves a material blind spot.
1. Cybersecurity Risk
The highest-priority domain in most assessments. It covers the vendor's ability to protect your data and systems from attack or breach.
What to assess:
- Security controls and frameworks in place (ISO 27001, SOC 2, etc.)
- Vulnerability management and patch management practices
- Access control policies and identity management
- Encryption standards for data at rest and in transit
- Incident detection and response capabilities
- History of breaches or security incidents
Key evidence to request:
- SOC 2 Type II report
- ISO 27001 certificate (and scope)
- Penetration test results (executive summary at minimum)
- Security questionnaire responses (SIG or CAIQ)
The balance to maintain: Cybersecurity risk is where most organisations focus, rightly — but it should not crowd out the other four domains. A vendor with excellent security controls can still fail you through operational unreliability, financial collapse, or regulatory non-compliance.
2. Operational Risk
A vendor that is secure but unreliable creates a different kind of problem. Operational risk covers the vendor's ability to keep delivering their service under adverse conditions.
What to assess:
- Business continuity plans (BCPs) and disaster recovery (DR) capabilities
- SLA track record and uptime history
- Geographic concentration (is the vendor's entire operation in one location?)
- Key person dependencies (what happens if their sole system administrator leaves?)
- Subcontractor reliance (who does the vendor outsource to?)
The scenario to understand this: A fintech company relied on a single third-party payment processor. When that processor experienced a prolonged outage, the fintech could not process any transactions for 72 hours. The outage was not a security incident. It was a business continuity failure — something a proper operational risk assessment would have flagged before the relationship began.
3. Compliance and Legal Risk
The vendor must meet the regulatory requirements that apply to your industry and the data they process. Their compliance gaps become your exposure.
What to assess:
- Data protection compliance (GDPR, UAE PDPL, and other applicable laws)
- Sector-specific regulatory certifications
- Contractual obligation tracking and evidence of compliance
- Handling of regulated data types (personal data, financial data, health data)
- Incident notification obligations and timelines
Important: If your vendor processes personal data on your behalf, you are the data controller and they are the processor. Under GDPR and most equivalent laws, the responsibility for ensuring the processor's compliance rests with you — not with the vendor.
4. Financial Risk
A vendor that goes out of business while processing your payroll or hosting your customer data is a serious problem, regardless of their cybersecurity posture.
What to assess:
- Financial stability indicators (revenue, profitability, funding runway)
- Credit ratings or financial health scores where available
- Concentration risk (is this vendor overly dependent on a single customer or contract?)
- Insurance coverage and indemnification capability
- Signs of financial distress (rapid executive turnover, cost-cutting in security functions)
5. Reputational and Ethical Risk
An association with a vendor engaged in unethical practices, data misuse, or publicised security failures carries reputational consequences for your own organisation.
What to assess:
- Public record of security incidents or regulatory actions
- Ethical practices and ESG commitments
- Alignment with your own acceptable use policies
- News and media monitoring for adverse reporting
- Subcontractor and supply chain ethical standards
The AI dimension: Vendors are increasingly embedding AI into their products and services, sometimes without clear disclosure. This introduces reputational dimensions — around data use, automated decision-making, and model transparency — that traditional assessment questionnaires were not designed to capture. AI vendor governance is becoming a distinct and important assessment category in its own right.
The Vendor Risk Assessment Lifecycle
Vendor risk assessment is not a single event. It is a continuous process that runs throughout the vendor relationship.
Phase 1: Pre-Onboarding Due Diligence
Before signing any contract, assess the vendor against all five risk domains. The depth of this assessment should match the vendor's risk tier.
At this stage:
- Define the scope of the relationship and what data and systems the vendor will touch
- Assign a risk tier based on criticality and exposure
- Conduct the appropriate level of due diligence for that tier
- Review and negotiate contractual protections
- Obtain formal risk acceptance from the appropriate level of leadership
Phase 2: Onboarding Controls
When a vendor goes live, ensure that:
- Access rights are provisioned at the minimum necessary level
- Integration points are documented and secured
- Vendor contacts for security and compliance are identified
- Incident escalation paths are established and tested
Phase 3: Ongoing Monitoring
Risk does not freeze at the moment of onboarding. Vendors change. Their financial position changes. Their security posture changes. Their subcontractors change.
Ongoing monitoring should include:
- Periodic reassessments at a frequency matched to risk tier
- Continuous external monitoring via security ratings tools
- Contract renewal reviews
- Triggered reassessments when significant changes occur (merger, breach, leadership change, new subcontractor)
Phase 4: Incident Response
When something goes wrong with a vendor:
- Have a vendor-specific incident response plan in place before you need it
- Know your contractual notification rights and timelines
- Have an exit or contingency plan for critical vendors
Phase 5: Offboarding
When a vendor relationship ends:
- Ensure your data is deleted or returned per contractual terms
- Revoke all access rights immediately
- Conduct a debrief if the relationship ended due to a risk or performance concern
- Update your vendor risk register
How to Tier Your Vendors
Not all vendors deserve the same level of scrutiny. Assessing every vendor at the same depth is neither practical nor necessary — and it leads to exhausted teams and very little actual risk reduction.
The standard approach is to tier vendors by risk and criticality:
| Tier | Description | Examples | Assessment depth |
|---|---|---|---|
| Critical | Access to sensitive data or systems; failure would significantly disrupt operations | Core cloud infrastructure, payroll processor, primary IT managed service provider | Full assessment across all five domains; annual reassessment; continuous monitoring |
| Important | Access to limited data or non-critical systems; failure would cause disruption but not critical impact | HR software with limited data access, marketing analytics tools | Standard assessment covering core domains; biennial reassessment |
| Standard | No access to sensitive systems or data; limited integration | Office supplies vendor, travel booking, training platform | Lightweight questionnaire or self-certification; triennial reassessment |
The tiering question to ask about every vendor:
If this vendor was breached, went offline, or ceased trading tomorrow — what would happen to our operations, our data, and our regulatory position?
The more severe the answer, the higher the tier.
Two common tiering mistakes:
- Tiering by contract value rather than risk exposure. A small vendor with access to your core customer database is higher risk than a large vendor providing you with office stationery.
- Under-tiering cloud providers. If your entire business runs on one cloud platform and that platform went down, the impact would be critical — regardless of how reliable that platform has historically been.
What to Actually Ask Vendors
The vendor security assessment questionnaire is the primary tool for gathering evidence about a vendor's security and compliance posture. Here is what it should cover, organised by domain.
Information Security Governance
- Does the vendor hold ISO 27001 certification? What is the scope?
- Do they have a dedicated information security function or CISO?
- Is there a formal, documented information security policy?
- When was information security last reviewed by senior leadership?
Data Protection and Privacy
- Where is your organisation's data stored, processed, and transmitted?
- Is data encrypted at rest and in transit? What standards are applied?
- Is data classified according to sensitivity, with defined protection requirements?
- How does the vendor handle data subject rights requests (access, deletion, portability)?
- What is the vendor's process for notifying you of a data breach, and within what timeframe?
Access Control
- How is access to your organisation's data provisioned and de-provisioned?
- Is multi-factor authentication (MFA) required for access to systems handling your data?
- Are third-party and subcontractor access rights subject to the same controls as internal staff?
- How frequently are access rights reviewed and recertified?
Incident Response
- Does the vendor have a documented, tested incident response plan?
- When was the last incident response test (tabletop or live drill)?
- What is the vendor's process for notifying customers in the event of a breach or outage?
- Has the vendor experienced a security incident in the past three years? If so, what happened and how was it resolved?
Business Continuity and Disaster Recovery
- Does the vendor have a documented business continuity plan?
- What are the recovery time objectives (RTO) and recovery point objectives (RPO) for the services they provide to you?
- When was the BCP/DR plan last tested?
- What is the vendor's process if a key person becomes unavailable?
Subcontractor and Supply Chain Risk
- Does the vendor use subcontractors to deliver the services they provide to you?
- If so, who are the material subcontractors and what do they do?
- What due diligence does the vendor conduct on its own suppliers?
- Are subcontractors subject to the same security requirements as the primary vendor?
Regulatory and Compliance
- What regulatory frameworks does the vendor comply with?
- What certifications or attestations does the vendor hold (SOC 2, ISO 27001, PCI DSS, etc.)?
- How does the vendor demonstrate ongoing compliance, not just point-in-time certification?
Evidence principle: Self-attestation — a vendor saying "yes" to every question — is the starting point, not the conclusion. Every material claim should be cross-validated against at least one external or documentary source: a certificate, an audit report, a third-party attestation, or a security rating.
How to Score and Rate Vendor Risk
Scoring converts assessment data into a consistent, comparable measure of the risk a vendor poses. Without a scoring model, risk classification becomes a negotiation between team members rather than a policy decision.
The components of a vendor risk score
A defensible vendor risk score draws on multiple inputs:
| Input | What it is | Limitation |
|---|---|---|
| Questionnaire responses | What the vendor says about their own controls | Subjective; requires cross-validation |
| Certifications and audit reports | SOC 2, ISO 27001, HITRUST — independent third-party validation | Point-in-time; lapsed certification is a red flag |
| Security ratings | External, continuous monitoring of observable signals (open ports, certificate lapses, known vulnerabilities) | Observable surface only; doesn't reflect internal controls |
| Engagement context | How the vendor is being used, what data they touch, how critical they are | Must inform weighting of all other inputs |
The principle that matters most: Active, current certifications should consistently outweigh self-attestation in scoring weight. A lapsed certification should trigger an automatic score review, not a manual follow-up request.
A simple scoring approach
- Define your risk dimensions: Cybersecurity, operational, compliance, financial, reputational.
- Weight them: Different weights apply based on the vendor's context. For a SaaS vendor handling sensitive data, cybersecurity carries the most weight. For a logistics provider, operational continuity may be more critical.
- Score each dimension: Low (1), Medium (2), High (3) — or a numerical scale if your programme needs more granularity.
- Calculate a composite score: Weighted average across dimensions.
- Map to a risk tier: Define thresholds. A score above X triggers enhanced monitoring. A score above Y triggers escalation to leadership for risk acceptance.
The test of a useful score: Can you explain to a board member or auditor exactly why a vendor received the score they did? If the answer is "we ran them through our system and this came out," that is not good enough. Scores need to be explainable.
Contracts and Vendor Agreements
The contract is not a formality at the end of the assessment process. It is where the risk management findings get translated into enforceable obligations.
What strong vendor contracts include
Security requirements:
- Minimum security standards the vendor must maintain
- Right to audit the vendor's security controls (or receive third-party audit reports)
- Obligation to maintain current certifications and notify you of any lapses
Incident notification:
- Specific timeframes for notifying you of a breach or security incident (often 24 to 72 hours depending on the regulatory context)
- What a "notifiable incident" includes
- Escalation path and contact details
Data handling:
- Exactly what data the vendor may process, and for what purpose
- Data residency requirements (where data must and must not be stored)
- Data retention and deletion obligations at contract end
Subcontractors:
- Obligation to notify you before engaging a new material subcontractor
- Right to object to subcontractors that introduce unacceptable risk
- Flow-down of security requirements to subcontractors
Business continuity:
- SLA commitments and remedies for failure
- Recovery time obligations in the event of an outage
- Obligation to maintain and test BCP/DR plans
Exit provisions:
- How your data will be returned or destroyed at contract end
- Transition assistance obligations
- Notice periods that give you sufficient time to transition to an alternative vendor
The most common contractual gap: Vague incident notification language. "Notify promptly" is not a contractual obligation — "notify within 24 hours of becoming aware of a material security incident affecting Customer data" is. Vague language creates delays and confusion exactly when speed and clarity are most critical.
Continuous Monitoring vs. Point-in-Time Reviews
A vendor risk assessment conducted at onboarding reflects the vendor's posture on one specific day. That snapshot can become outdated within weeks.
What changes between assessments:
- Vendors get breached — and may not immediately disclose it
- Certifications lapse without being renewed
- Financial positions deteriorate
- Key security staff leave
- New subcontractors are added without notice
- Acquisitions change the vendor's ownership and security culture
- New products introduce new data processing activities
Point-in-time assessments: what they're good for
Annual or biennial reassessments are still valuable — they allow for a structured, comprehensive review across all risk domains and provide the documented evidence that auditors and regulators expect to see.
Continuous monitoring: what it adds
Continuous monitoring provides signals between formal assessment cycles:
- Security ratings platforms monitor externally observable signals — open ports, certificate lapses, known vulnerabilities, dark web exposure
- News and media monitoring surfaces public incidents, regulatory actions, or adverse reporting
- Threat intelligence feeds provide early warning of attacks targeting vendor platforms or sectors
Important caveat: Security ratings reflect the observable external surface of a vendor's environment. They do not reflect internal controls. A vendor can have an excellent external security rating and still have poor access controls, no tested incident response plan, and no business continuity capability. Ratings complement assessment data — they do not replace it.
Triggered reassessments
Certain events should automatically trigger a reassessment regardless of where a vendor sits in the regular cycle:
- The vendor announces a data breach or security incident
- A material change in ownership (merger, acquisition, private equity buyout)
- Significant leadership change (new CEO, CTO, or CISO)
- The vendor adds a material new subcontractor
- A regulatory action or fine affecting the vendor
- A significant contract renewal or scope expansion
- Your organisation's risk appetite or regulatory obligations change
Regulatory Requirements You Need to Know
Vendor risk assessment is increasingly embedded in regulatory frameworks across every major jurisdiction. The table below reflects the landscape as understood at the time of writing — specific requirements evolve, but the underlying direction across all of these frameworks is consistent and well-established.
| Framework | Who it applies to | What it requires |
|---|---|---|
| DORA (EU) | Financial institutions and their ICT providers | Classify critical ICT vendors, maintain risk registers, conduct ongoing due diligence, test operational resilience |
| GDPR / UK GDPR | Any organisation processing EU/UK personal data | Written contracts with processors, due diligence on processing activities, documented lawful basis |
| ISO 27001 (A.5.19) | Any certified organisation | Assess and agree information security requirements with all suppliers |
| NESA / UAE IAS | UAE government entities and critical infrastructure | Supply chain risk management controls, vendor security assessments |
| CBUAE | UAE banks, fintechs, payment service providers | Assess and monitor cybersecurity posture of all material technology vendors |
| NYDFS 23 NYCRR 500 | NY-licensed financial services companies | Vendor risk assessments, strong authentication requirements, breach notification |
| PCI DSS | Any organisation handling payment card data | Due diligence on service providers, contractual security requirements, monitoring of compliance |
The pattern across all of them: Regulators are not satisfied with an organisation saying, "we trust our vendors." They want evidence of structured, documented due diligence conducted before engagement and maintained throughout the relationship. That expectation is not going to weaken over time.
Common Mistakes and How to Avoid Them
Assessing at onboarding and then forgetting about it
The most widespread failure in vendor risk management. Assessments get done, contracts get signed, and then nothing happens for years. Vendors change. Your relationship with them changes. The risk changes.
Fix: Build reassessment triggers into your vendor management process. Set calendar reminders for annual or biennial reviews. Automate alerts for external signals that warrant an earlier look.
Tiering vendors by contract value rather than risk
A vendor charging you £500 a month might still have access to your entire customer database. A vendor billing you £500,000 a year might only supply you with branded merchandise.
Fix: Tier vendors based on data sensitivity, system access, and operational criticality — not the size of their invoice.
Accepting self-attestation as evidence
A questionnaire where the vendor answers "yes" to every question is not evidence. It is a starting point.
Fix: Cross-validate material claims against independent evidence — current certificates, third-party audit reports, security ratings, or contractual verification rights.
Missing the fourth party problem
Your vendor has vendors of their own. If your critical cloud provider relies on a single data centre operated by a third party, and that data centre has a failure, your exposure is real even though your contract is with the primary vendor.
Fix: Ask critical vendors about their own vendor risk management practices. Understand material subcontractors. Include contractual clauses requiring notification of material subcontractor changes.
Sending the same questionnaire to everyone
A 200-question security assessment sent to the company providing your office coffee machine is wasted effort. A 20-question lightweight questionnaire sent to your payroll processor is a serious gap.
Fix: Match assessment depth to vendor tier. Your critical vendors get the full assessment. Your standard vendors get a proportionate, shorter review.
Weak incident notification clauses
"We will notify you promptly" means nothing when there is a breach at 2am and your legal team is arguing with the vendor's legal team about whether 72 hours has elapsed.
Fix: Define notification timelines precisely in contracts. Specify what triggers a notification obligation. Include escalation contacts on both sides.
Treating vendor risk as an IT problem
Vendor risk affects operational continuity, financial exposure, regulatory compliance, and customer trust. All of these are business issues, not technology issues.
Fix: Bring procurement, legal, finance, compliance, and business operations into your vendor risk programme. The risk decisions need to be owned by the business, not delegated entirely to IT.
Building a Programme That Scales
Start with your vendor inventory
You cannot assess risk you do not know exists. Before anything else, build a complete inventory of every vendor your organisation uses — including the ones individual teams have adopted without central oversight, the SaaS tools on expense accounts, and the cloud infrastructure running in the background.
Most organisations discover they have significantly more vendor relationships than their official records suggest. This is one of the most common and most important findings in any vendor risk programme.
Build a risk register
A vendor risk register is a living document that records:
- All vendors in scope
- Their assigned risk tier
- Last assessment date and outcome
- Outstanding remediation actions and deadlines
- Next scheduled reassessment date
- Risk acceptance decisions and who approved them
Without a risk register, your programme exists only in the memory of the team members who ran the last assessment. When that team changes, the programme resets.
Define clear ownership
Every vendor relationship should have a named internal owner — someone responsible for maintaining the relationship, ensuring assessments happen on schedule, and escalating risk concerns. Without named ownership, assessments get deprioritised and risk decisions get made by default rather than by design.
Integrate with procurement
The most effective vendor risk programmes start before a vendor relationship begins — by embedding risk assessment requirements into the procurement process. A risk assessment should be a prerequisite for any new vendor engagement above a defined threshold, not an afterthought once contracts have already been signed.
Use shared assurance frameworks to reduce duplication
A significant portion of vendor risk assessment effort is consumed by chasing documentation and managing questionnaires. Vendors with current ISO 27001 certifications, SOC 2 Type II reports, or similar third-party attestations reduce your assessment burden considerably.
Where a vendor holds a relevant current certification, you can often reduce or eliminate specific questionnaire sections and focus your effort on the vendor-specific and context-specific questions that standard frameworks do not address.
Scale assessment depth, not programme scope
As your organisation and vendor ecosystem grows, the answer is not to assess fewer vendors — it is to ensure that assessment depth is proportionate to risk. A well-designed programme can handle a large vendor portfolio by applying lightweight processes to lower-tier vendors and reserving intensive due diligence for the vendors that genuinely warrant it.
This guide is designed as a durable reference — the principles, processes, and practices described here are built to remain relevant as the vendor landscape and regulatory environment continue to evolve. For decisions with legal or regulatory consequences, consult qualified legal and compliance professionals.
