A vendor assessment can look thorough and still tell us very little about where the business is exposed. Getting the questionnaire back is the easy part. The harder work is deciding which answers matter, what evidence supports them, and what to do when something is wrong.
That is where I would start with third-party risk management (TPRM): give the vendors that can cause the most damage the most attention.
Verizon's 2026 Data Breach Investigations Report, which analyzes 2025 data, found third-party involvement in 48% of breaches—a 60% increase over the previous report's share. With nearly half of breaches involving a third party, the practical question is: where should a security team with limited time begin?
Start with the role the vendor plays
Start with what the vendor will actually do. A supplier printing public brochures creates a very different exposure from a service that stores employee records or has administrative access to production systems. Sending both the same lengthy questionnaire wastes time and makes security harder to work with.
I would ask the business owner to complete a short intake before purchasing or granting access. It should establish:
-
What data the vendor will access, including its sensitivity and volume
-
What permissions and connections the service needs
-
Which business processes depend on it and how long they can tolerate an outage
-
Where data will be processed and which subcontractors are involved
-
How difficult it would be to replace the service or recover without it
These answers help establish inherent risk: the exposure the relationship creates before we account for the vendor's safeguards. Security should help validate the answers, especially when a business owner isn't sure what access the service needs.
Apply the same intake to free SaaS tools, browser extensions, and developer plugins. They may never appear in procurement records yet still access sensitive data or systems. Contract value should never determine the risk tier.
Keep the scoring simple, but build in escalation rules. Privileged access or highly-sensitive data should trigger deeper scrutiny even when other answers look harmless. An average score should never hide a serious exposure. Equally, a small dataset can contain valuable intellectual property; record count alone is a poor shortcut.
Plan for a vendor outage
Operational dependence deserves particular attention. On March 10, 2026, Nebius experienced a regional outage during a supplier's power infrastructure maintenance. Its incident review documented a region-wide loss of external virtual machine connectivity for nearly two hours, with further interruptions during recovery. The incident shows how a vendor's own suppliers can affect the services we depend on.
For me, the lesson is to include recovery in the assessment. Can we restore essential services if this vendor fails? Have we tested that plan? Do several apparently separate suppliers depend on the same underlying platform? Those answers can reveal exposure that a data privacy review would miss.
Match the review to the risk
Once the risk is understood, match the review to it. A supplier with no sensitive data, system access, or meaningful operational role may need only a documented screening. A service handling internal information may warrant targeted checks of authentication, encryption, retention, and incident notification. A critical provider deserves deeper examination of relevant controls, access paths, recovery tests, and dependencies.
Make use of the evidence the vendor already has. For a SOC 2 report, check that it covers the service you're buying, how recent it is, what exceptions were found, and which controls your own team must put in place. Then follow up on gaps that affect your use case.
The Checkmarx supply-chain incident identified in March 2026 illustrates why specific controls matter. Checkmarx said the Trivy compromise enabled unauthorized access to its GitHub repositories, followed by the distribution of malicious developer tools. Its July update confirmed containment and no attacker access to the Checkmarx One SaaS environment. The affected component and distribution channel mattered.
My takeaway is to examine the exact integration. What can a plugin or automated workflow access? How are its credentials restricted and revoked, and how are software releases verified? Those questions connect the assessment to the paths an attacker could exploit.
Follow through on the findings
Finding a gap is only useful if someone acts on it. Conditional approval can make sense when the remaining risk is understood and acceptable. Be clear about what needs fixing, who owns it, what safeguards apply in the meantime, and when the work is due. Agree upfront on the evidence needed to close the issue and what happens if the deadline slips.
Some findings should delay access or onboarding. Missing protection on a privileged access route cannot be treated like an overdue policy update. The business decision must reflect the potential consequences, with acceptance by someone authorized to own the risk.
Revisit the review when things change
After onboarding, keep reviews focused on meaningful changes. Ask about new integrations, expanded data access, subcontractors, security incidents, and changes to the service. An AI feature that sends information to another provider can materially change the original assessment. Reassess when that happens, even if the annual review is months away.
Automation can help extract evidence and flag changes, provided a reviewer checks the underlying sources. External monitoring can prompt investigation, but a clean score cannot establish that internal controls work.
Keep a concise decision record: the risk tier and its rationale, evidence reviewed, unresolved findings, approval, and next review trigger. That record should let another person understand why the organization accepted the relationship.
I would track how many critical services have tested recovery plans, which findings are overdue, and whether reviews happen before access is granted. Turnaround time matters too; it helps us see where the process is slowing people down.
The aim is to make vendor decisions that people can explain and act on. Security earns trust when it focuses attention where failure would hurt most and follows through on what it finds.
