“A vendor risk assessment should help organizations identify where third-party access, technology, and dependencies could introduce meaningful security exposure.” – IOActive Security Team
Vendors may have security policies in place, but those policies do not always show how much risk their access and technology create for your organization. A useful assessment looks beyond the policy document to the attack paths a compromised vendor could open.
Use this vendor risk assessment template free of charge to establish scope, test evidence quality, and determine when a vendor relationship warrants technical validation. This framework aligns with NIST SP 800-161 Rev. 1, which addresses the identification, assessment, and mitigation of cybersecurity supply chain risk, and the NIST Cybersecurity Framework 2.0 C-SCRM guidance, which prioritizes vendors by criticality and expects vendor risk to be monitored throughout the relationship.
Vendor Risk Assessment Template
The matrix below is the core template. Add an owner, a due date, and a progress update for each follow-up item.
Core Vendor Risk Assessment Template
| Assessment domain | Questions to ask | Evidence to request | Escalate when |
| Data access and handling | What data is collected, stored, transmitted, or generated? | Data-flow diagram, retention policy, subprocessors | Sensitive data leaves approved regions or lacks deletion controls |
| Authentication and access | How are workforce, customer, privileged, and service accounts protected? | Multi-factor authentication (MFA) standard, access review record, privileged access design | Shared accounts, unmanaged service accounts, or weak recovery paths appear |
| Security controls | Which preventive, detective, and corrective controls protect the service? | SOC 2 report, ISO 27001 certificate, control summary | Evidence is expired, narrow in scope, or vague |
| Vulnerability management | How are flaws found, triaged, fixed, and communicated? | Vulnerability policy, scan summary, remediation targets | Critical issues lack owners, deadlines, or customer notification rules |
| Incident response | How will the vendor detect, contain, investigate, and report an incident? | Incident plan, notification terms, exercise summary | No tested process or clear customer communication path exists |
| Software and product security | How are code, dependencies, builds, updates, and releases secured? | Secure development lifecycle (SDL) overview, Software Bill of Materials (SBOM), secure release controls | The vendor cannot explain update integrity or dependency risk |
| Infrastructure dependencies | Which cloud, hosting, identity, network, and fourth-party providers support delivery? | Architecture diagram, resilience plan, dependency list | A hidden dependency can interrupt a critical service |
| Regulatory considerations | Which contractual, privacy, sector, or geographic requirements apply? | Compliance mapping, data-processing terms, audit rights | Requirements are treated as badges rather than operating controls |
| Ongoing monitoring | What changes trigger reassessment, notification, or approval? | Review cadence, change process, service metrics | Risk is reviewed only at onboarding or renewal |
The escalation column is the operational center of the template. It converts a completed questionnaire into decisions about access, evidence, remediation, and technical validation.
1. Data Access, Handling, and Authentication
Start with the path to impact. Determine what a compromised vendor account, integration, administrator, service account, or update process could reach from the relationship. Do not accept “the vendor encrypts data” as a complete control description. Identify where encryption begins and ends, who can decrypt the data, how keys are governed, and whether support personnel can access production records.
Apply the same discipline to authentication. “Multi-factor authentication enabled” is incomplete if privileged access, API keys, recovery flows, and non-human accounts follow different rules.
Access and Authentication Signals
| Signal | What it may indicate | Useful follow-up |
| Broad network connectivity | A vendor compromise could become a pivot into internal systems | Request segmentation and least-privilege diagrams |
| Production access for support personnel | Human or credential abuse could affect live data | Review just-in-time access, approvals, and session logging |
| Long-lived API keys | Stolen credentials may remain useful after personnel changes | Ask about rotation, scope, expiration, and detection |
| Unclear data deletion | Data may persist after the contract ends | Confirm deletion timelines, backups, and verification |
These signals distinguish a limited data-processing role from a viable route into higher-value assets. The next step is to test whether the stated controls cover that route.
2. Security Controls and Vulnerability Management
Assess whether controls operate in the systems that support your relationship. Request enough detail to establish ownership, coverage, operating frequency, exceptions, and evidence retention.
For vulnerability management, ask how the vendor handles flaws in proprietary code, open-source components, cloud configuration, and externally exposed services. The relevant question is whether it can discover, prioritize, remediate, and communicate weaknesses before they create downstream exposure.
Control Evidence Matrix
| Control area | Evidence that helps | Warning sign |
| Asset inventory | Scope statement and inventory ownership | The vendor cannot define what is in scope |
| Vulnerability management | Remediation policy and recent summary | Severity is tracked without business impact |
| Configuration security | Baselines, review records, or cloud controls | Defaults remain in production without justification |
| Logging and detection | Coverage map and retention details | Critical actions are not attributable to a user or service |
| Backup and recovery | Recovery objectives and exercise results | Recovery claims are not tested |
| Exceptions | Risk acceptance records and expiry dates | Exceptions have no owner or end date |
A SOC 2 report, an ISO 27001 certificate, a penetration test summary, or a similar document can support an answer. It does not establish that every system relevant to your relationship is secure today. Check the assessment period, scope, exclusions, testing method, and unresolved findings.
Once control coverage and evidence quality are understood, the assessment should address the vendor’s ability to coordinate in the event of a compromise or service disruption.
3. Incident Response and Operational Resilience
A vendor incident can become a major problem when its systems process your data, connect to your network, or support a critical business function. The assessment should therefore examine coordination, evidence preservation, notification, and recovery, not only the existence of an internal response plan.
Ask who contacts your organization, how quickly the vendor must notify you, what evidence will be preserved, and how your teams will participate in containment. Confirm whether the vendor has exercised scenarios involving credential theft, ransomware, cloud compromise, data exposure, and loss of a key subprocessor.
Incident Readiness Matrix
| Question | Stronger answer | Deeper investigation trigger |
| Who declares an incident? | Named decision-makers and an escalation tree | Responsibility depends on an unnamed team |
| How are customers notified? | Contract terms and tested communication channels | Notification is “as soon as practical” with no process |
| What evidence is preserved? | Defined logs, timestamps, and retention rules | Forensic support is not addressed |
| How does service recover? | Recovery objectives supported by exercises | Recovery depends on an untested assumption |
| How are lessons tracked? | Post-incident actions have owners and deadlines | Reports close without corrective action |
These answers determine whether your organization can make informed decisions during an incident. Because NIST treats supply chain risk as a lifecycle concern, resilience and incident coordination belong in vendor governance, not only in the security team’s incident plan. The assessment can then move below the policy layer to examine the software, products, and infrastructure that create the vendor’s attack surface.
4. Software, Product Security, and Infrastructure Dependencies
Questionnaires provide limited assurance when the relationship depends on complex technology. If a vendor ships software, manages infrastructure, or embeds components in a product, assess how it engineers and maintains security across the lifecycle.
For SaaS applications, review tenant isolation, identity integration, logging, administrative access, and customer-data boundaries. For software, review the development lifecycle, code review, dependency management, build pipeline, release signing, update process, and vulnerability disclosure path. For hardware or embedded products, include firmware, debug interfaces, default credentials, update mechanisms, and manufacturing or support channels.
For infrastructure, map the services beneath the vendor’s service. A cloud provider, identity platform, managed service provider, hosting region, or fourth-party dependency may become a constraint that the vendor cannot quickly replace.
Technology Relationship Review
| Technology relationship | Examine | Validate when |
| SaaS application | Tenant isolation, identity, logging, integrations | The service connects to privileged systems or sensitive data |
| Software component | Build pipeline, dependencies, release integrity, Software Bill of Materials (SBOM) | The component runs in production or handles trusted input |
| Hardware or embedded product | Firmware, update path, debug access, support channels | The product controls physical processes or safety functions |
| Managed infrastructure | Segmentation, administrator access, resilience, fourth-party providers | Outage or compromise would interrupt critical operations |
An attacker-oriented assessment can expose assumptions that documentation leaves untested. Ask which trust boundary an attacker would target first, which control would be bypassed, and which asset would be exposed if that control failed.
For example, a vendor may require remote support access, expose an administrative API, and rely on a fourth-party identity provider. Those dependencies can combine into an attack path that is not visible in any single questionnaire response. The answers inform the regulatory and monitoring requirements that govern the relationship.
5. Regulatory Considerations and Ongoing Monitoring
Regulatory requirements should shape the assessment, but they should not substitute for it. Identify the laws, sector rules, contractual duties, data-location limits, breach obligations, retention requirements, and audit rights that apply to the relationship.
Then convert each requirement into an operating question.
- Who owns the control?
- Which system enforces it?
- What record proves it operated?
- What happens when the vendor changes a subprocessor, moves data, introduces a new integration, or experiences a material incident?
The NIST CSF 2.0 C-SCRM guidance calls for due diligence before a relationship begins. NIST CSF 2.0 also calls for understanding, recording, prioritizing, assessing, addressing, and monitoring vendor risks over time.
Lifecycle Monitoring Matrix
| Change event | Reassess this area | Minimum action |
| New data type or use | Data handling and privacy | Update the data flow and contract terms |
| New integration | Access, authentication, and segmentation | Review permissions and test the connection |
| Acquisition or ownership change | Governance, personnel, and dependencies | Request an updated risk profile |
| New subprocessor | Fourth-party dependency and geographic exposure | Review the subprocessor before approval |
| Material incident | Detection, response, and residual risk | Track corrective actions to closure |
| Major product release | Software, product, and update security | Review release and change controls |
An annual review may be appropriate for a low-impact vendor. It is not a universal control. Continuous monitoring should track material changes, while formal reassessment should occur according to access, criticality, change rate, and plausible business impact.
These triggers identify when a questionnaire requires technical validation. A vendor’s risk profile changes with its architecture, ownership, software, or data flows.
6. When a Questionnaire Is Not Enough
A questionnaire is insufficient when the answer depends on technical behavior that the vendor cannot demonstrate with policy documents. This does not mean every vendor requires a penetration test. It means the assurance method must correspond to the consequence of being wrong.
Use targeted technical validation when the vendor has privileged access, handles sensitive or regulated data, supports a critical process, ships software or hardware, exposes internet-facing services, relies on opaque fourth-party providers, or provides evidence that is incomplete, stale, or outside the relevant scope.
These scenarios are illustrative, not a severity ranking. Use the vendor’s access, criticality, evidence quality, and business impact to determine the escalation path.
Evidence Sufficiency and Escalation Matrix
| Questionnaire result | What does it tell you | Better next step |
| Complete answers, low-impact service | Basic risk is understood | Record the decision and monitor material changes |
| Strong documents, high-impact access | Control design may be credible | Validate scope, access paths, and technical assumptions |
| Vague answers, critical dependency | Risk is not measurable | Require evidence before onboarding or restrict access |
| Product with update or build authority | The vendor can influence trusted code | Review product security, release integrity, and dependencies |
| Repeated exceptions or delayed remediation | Risk may be systemic | Conduct targeted testing or an independent assessment |
| Major incident with unclear lessons | Residual risk is unknown | Require root-cause evidence and corrective-action tracking |
Possible validation methods include architecture review, configuration review, attack-surface analysis, secure code review, product security testing, cloud control validation, adversary simulation, and targeted penetration testing. Select the method according to the attack path, not the vendor’s preferred deliverable, and record the rationale for the escalation decision.
7. Scoring and Prioritizing Findings
Avoid a single score that conceals the reason for the risk. Record business criticality, access level, data sensitivity, and confidence in the evidence. A high-impact vendor with strong evidence may be acceptable, while a lower-impact vendor with privileged access and weak evidence may warrant faster intervention. The score should support a decision, not create false precision.
Vendor Risk Decision Matrix
| Priority | Typical condition | Decision |
| Low | Limited access, low-impact service, clear evidence | Approve with routine monitoring |
| Moderate | Sensitive data or meaningful integration, controls mostly supported | Approve with tracked remediation |
| High | Privileged access, critical dependency, or major evidence gaps | Escalate to security and business owners |
| Critical | Plausible path to material compromise with no timely mitigation | Delay, restrict, or reject the relationship |
For every finding, record the affected asset, attack path, business consequence, evidence, owner, due date, and acceptance authority. A finding without an owner is a future repeat finding.
This structure distinguishes inherent risk, control effectiveness, residual risk, and management acceptance before approval or renewal.
IOActive helps organizations assess vendor and supply chain risk from an attacker’s perspective, identifying technical exposure across third-party products, software, infrastructure, and access pathways.