Start with your business, then assess the vendor

Before I ask a vendor to prove its controls, I want to understand what we depend on it for. Which business process does it support? What can it access? What stops working if it disappears tomorrow?

Those answers tell me where a deeper review deserves my time. They also tell me who needs to be involved. A security questionnaire can help investigate a supplier, but the business has to explain the relationship we are investigating.

That is where I would start a third-party risk management program. I want a usable picture of our dependencies early enough to shape the assessment, the contract, and the decision to proceed.

Start with the service people rely on

A vendor name is an incomplete unit of analysis. One supplier might support several services with different data, integrations, owners, and recovery arrangements. A familiar company can provide a minor convenience in one part of the business and a critical dependency in another.

I want the intake conversation to identify the actual use case. “We need this platform” becomes “Our operations team uses this platform to assign tomorrow’s work.” That sentence gives us a process, an owner, and a reason availability matters.

It also makes follow-up questions more useful. How are assignments delivered? Who can change them? Can the team operate without the platform? What happens during the busiest week of the year?

A hypothetical scheduling supplier

Consider a fictional organization that uses a third-party scheduling service to coordinate field teams. This is an illustrative example, not a description of a company or assessment I have worked on.

The initial request calls it a scheduling tool. The service owner explains that it holds worker contact details and location assignments. It receives updates from an internal system through an integration account. Supervisors depend on it to tell people where to go each morning.

Now suppose the vendor becomes unavailable overnight. A short outage might be manageable if supervisors have a recent export and a practiced fallback. The same outage could disrupt operations if the only schedule exists inside the unavailable service.

The vendor has not changed between those situations. Our dependence and ability to recover have. That difference should influence how we investigate availability, export capability, recovery commitments, and the internal contingency plan.

Map the paths into the business

I use “blast radius” to describe where a failure or compromise could reach. To make that phrase useful, I need specific relationships: the supplier supports a service, the service uses particular data, an account connects systems, and a business owner depends on the result.

For the scheduling example, I would trace what the integration account can read or change. Broad permissions could introduce a different exposure from an account limited to uploading schedules. I would also ask who administers access and what happens when the relationship ends.

Fourth parties matter where they create meaningful dependencies. If the scheduling supplier and our fallback both rely on the same underlying provider, the fallback may be less independent than it appears. I would record that question and seek evidence before treating it as an established weakness.

A service catalog, asset inventory, or configuration management database can help. So can a conversation with the person who actually runs the process. I would connect those sources and make missing information visible rather than wait for a perfect inventory.

Let the context shape the review

I would use this information to support consistent tiering and explain the review priority. Mapping dependencies does not automatically move vendors into lower tiers. It may reveal that a supposedly minor tool deserves more attention.

The criteria need to be explicit enough that two reviewers can explain their decisions. Service importance, sensitive data, access, concentration, and recovery options all deserve consideration. A high-impact dependency can still have strong controls; criticality and control effectiveness answer different questions.

For the fictional scheduling service, I would focus evidence requests on the access paths and operational dependencies we identified. I would investigate how integration credentials are protected, whether access is reviewed, and whether recovery evidence covers the service we will use.

This makes document review more purposeful. When reading an assurance report, I want to understand whether its scope and period address our questions and what responsibilities remain with us. The existence of a report alone does not resolve the relationship’s exposure.

NIST’s supply-chain quick-start guide is a useful companion here: it connects establishing a cybersecurity supply-chain capability with defining and communicating supplier requirements. The business context helps make those requirements specific.

Connect the findings to a decision

Suppose the review establishes that schedule exports are available, but nobody internally owns the fallback process. Another questionnaire to the vendor will not assign that responsibility. The next action belongs inside our organization.

Other findings may call for a supplier change, a narrower integration, a recovery exercise, or a requirement to address during contracting. I want the assessment to identify the owner of each action and the decision it supports.

That is why I enjoy the conversation with the business. People explain constraints that a document cannot supply: an upcoming launch, a seasonal peak, a difficult migration, or a dependency that nobody recorded. Those details change what a practical response looks like.

Keep the relationship current

The approved use case will evolve. A team may add personal data, enable a new integration, expand usage, or lose its backup provider. I want those changes to trigger a fresh look at the relevant assumptions.

Automation can help collect and route changes. AI can help organize evidence and prepare questions. My proposed AI-first TPRM operating model explores that direction. The foundation remains a relationship we understand well enough to recognize when it changes.

Five questions to take into your next intake

1. Which business service depends on this supplier, and who owns the outcome?
2. What data and system access will the supplier actually need?
3. What could stop, be exposed, or be changed if the service fails or is compromised?
4. What recovery options exist, and what evidence shows they would work?
5. Which changes should trigger another review, and who will tell us they happened?