Supply Chain Security: How to Build a Risk-Based Third-Party Risk Management Program

Watch the Session

Cheri walks through third-party risk, fourth-party dependencies, vendor tiering, inherent and residual risk, questionnaires, shared responsibility, ongoing monitoring, critical-vendor due diligence, and how small teams can build a program they can actually sustain.

The Short Answer

Supply chain security is the practice of understanding and managing the risk created by the vendors, suppliers, service providers, cloud platforms, partners, and other third parties an organization depends on.

The goal is not to send every vendor the same questionnaire or collect as many certifications as possible. It is to identify which relationships create meaningful risk, evaluate that risk, apply appropriate due diligence and controls, monitor changes over time, and determine whether the remaining risk is acceptable.

A strong third-party risk management program therefore needs prioritization, lifecycle management, clear ownership, shared-responsibility analysis, ongoing monitoring, and enough flexibility to go deeper where the risk actually matters.

Key Takeaways

• Every vendor relationship introduces risk. The question is not whether risk exists, but whether the organization understands and manages it appropriately.
• Third-party risk management is not a compliance exercise. Compliance may trigger the process, but the purpose is risk reduction.
• Not every vendor deserves the same level of scrutiny. Organizations need to prioritize based on inherent risk, including data access, system access, business criticality, and operational dependency.
• Vendor risk extends beyond the third party. Fourth-party and deeper supply-chain dependencies can matter when they affect critical services or sensitive data.
• Vendor management is a lifecycle. Identification, assessment, onboarding, monitoring, reassessment, and offboarding all matter.
• Questionnaires should be actionable. Asking hundreds of questions provides little value if nobody has the capacity or intent to analyze the answers.
• Shared responsibility must be understood. A vendor’s certification does not mean the customer has no security responsibilities.
• The program must be sustainable. An overbuilt TPRM program can fail just as easily as an underbuilt one if the organization cannot operate it consistently.

Why Is Supply Chain Security a Risk Management Problem?

Organizations rarely operate independently anymore. They depend on cloud providers, software platforms, payment processors, consultants, managed service providers, data processors, infrastructure providers, and countless other suppliers.

Each relationship creates some level of exposure.

That exposure may involve confidentiality, system access, operational continuity, financial stability, regulatory requirements, customer commitments, reputation, or a combination of several risks.

That is why vendor risk should fit inside the organization’s broader risk-management process rather than operate as an isolated compliance activity.

Who Owns Third-Party and Supply Chain Risk?

The vendor owns the risk of its organization. The customer owns the risk of its organization.

When a company chooses to rely on a supplier to provide a service, process data, support infrastructure, or contribute to a customer offering, it does not transfer accountability for the resulting business risk.

If the supplier experiences a disruption or breach, customers will generally look to the company they contracted with — not accept “that was our vendor” as the end of the explanation. That is why organizations need visibility into the risks created across their vendor ecosystem.

What Are Third-Party, Fourth-Party, and Nth-Party Risks?

A third party is a vendor or supplier the organization works with directly.

A fourth party is one of that vendor’s vendors. Additional dependencies further down the supply chain are sometimes referred to as nth parties.

Organizations do not need to investigate every fourth- or fifth-party relationship associated with every supplier. That would quickly become unsustainable.

The key is to understand where deeper dependencies matter. If a critical supplier relies heavily on another provider whose failure could disrupt the service the organization depends on, that relationship may deserve attention.

Why Should Organizations Prioritize Vendors by Risk?

Most organizations have too many suppliers to perform deep due diligence on all of them.

Trying to treat every vendor as critical usually creates one of two outcomes: the team becomes overwhelmed, or the process turns into a shallow checkbox exercise.

A risk-based model allows the organization to spend more time where the potential impact is higher and less time where exposure is minimal.

That makes the program both more defensible and more sustainable.

What Makes One Vendor Riskier Than Another?

Cheri recommends starting with a few practical questions:

• What sensitive or regulated data can the vendor access?
• What systems or environments can the vendor access?
• How critical is the vendor to business operations?
• What would happen if the vendor became unavailable?
• What customer or regulatory obligations depend on the vendor?
• Does the vendor create meaningful financial or reputational exposure?
• How difficult would the vendor be to replace?

The point is to evaluate the full risk picture rather than limiting TPRM to technical controls or regulated data alone.

What Is Inherent Risk vs. Residual Risk in TPRM?

Inherent risk is the risk associated with a vendor relationship before considering the controls or mitigating activities that reduce that risk.

Residual risk is what remains after those controls and mitigating activities are considered.

For example, a vendor handling highly sensitive data or operating a business-critical system may begin with high inherent risk. Assurance reports, strong contractual protections, technical controls, monitoring, evidence review, redundancy, and other safeguards may reduce that risk.

The organization then decides whether the remaining residual risk is acceptable or whether additional action is required.

How Should Organizations Tier Their Vendors?

There is no single required vendor-tiering model.

Some organizations use Tier 1, Tier 2, and Tier 3 categories. Others calculate individual risk scores. Some separate vendors by data exposure, operational criticality, system access, or business impact.

The exact method matters less than whether the model consistently identifies which suppliers deserve deeper diligence.

A critical vendor may require detailed evidence review, direct conversations, additional contractual rights, ongoing monitoring, or even onsite validation. A low-risk vendor may require little more than basic due diligence.

Why Isn’t an Annual Vendor Review Enough?

Annual due diligence is a useful minimum cadence, but vendor risk does not change only once a year.

Organizations should also reevaluate vendors when meaningful changes occur, such as:

• The service being provided changes
• The vendor begins receiving additional data
• System or network access changes
• The vendor experiences a security incident or disruption
• An assurance report changes materially
• The vendor’s financial or operational condition changes
• External events create new risk

A mature program therefore combines scheduled reviews with event-driven monitoring.

What Should the Vendor Lifecycle Include?

Third-party risk management should cover the entire vendor relationship.

1. Identify the vendor. Know which suppliers exist across the organization.
2. Assess inherent risk. Understand the exposure before controls are considered.
3. Perform appropriate due diligence. Match the depth of review to the level of risk.
4. Onboard intentionally. Establish expectations, responsibilities, access, contractual protections, and security requirements.
5. Monitor the relationship. Watch for security, operational, performance, and business changes.
6. Reassess. Update risk when conditions materially change.
7. Offboard completely. Remove access, stop data transfers, and address retention, return, or deletion of organizational data.

Offboarding is especially easy to overlook, yet terminated vendors may still retain access or continue receiving data if the end of the relationship is not managed carefully.

Why Are Vendor Questionnaires Often Ineffective?

Questionnaires can be useful, but only if the organization intends to evaluate and act on the answers.

A 500-question form does not automatically provide better risk management than a 50-question form.

If the TPRM team does not have enough time or expertise to analyze 500 responses, investigate exceptions, and make risk decisions, the extra questions may simply create work for both organizations without improving assurance.

Different vendors may also require different questionnaires depending on data access, regulated information, system access, business criticality, and available assurance.

Is a SOC 2 Report or ISO Certification Enough for Vendor Due Diligence?

Sometimes it may be sufficient. Sometimes it may only be one input.

The answer should depend on the risk of the relationship.

For a lower-risk vendor, an appropriate assurance report may provide enough comfort. For a high-risk or critical supplier, the organization may need to understand scope, exceptions, customer responsibilities, service boundaries, evidence, contractual protections, and areas not covered by the report.

The goal is not to collect the certification. The goal is to determine what assurance the certification actually provides for the relationship the organization has with that vendor.

How Should Vendors Respond to Customer Security Questionnaires?

Organizations receiving customer questionnaires do not necessarily need to answer every question from scratch.

If a reputable SOC 2 report, security package, white paper, or other assurance material already answers a question, the vendor can point the customer to that information and invite additional questions about areas that remain unclear.

That approach respects the customer’s need for assurance without creating unnecessary repetitive work.

The underlying relationship should remain transparent and collaborative: the customer is trying to determine whether it can rely on the vendor’s risk management, not simply collect another completed form.

What Does Shared Responsibility Mean in Third-Party Risk?

Shared responsibility defines what the provider is responsible for and what the customer must still do.

Even with SaaS, customers usually retain responsibilities such as user access, configuration, data handling, authentication, or other controls.

As organizations move from SaaS into platform and infrastructure services, those boundaries often become more complex.

A strong TPRM process makes those responsibilities explicit rather than assuming the vendor “handles security.”

Why Is Operational Risk Part of TPRM?

Vendor risk is broader than cybersecurity and data privacy.

A supplier may never touch regulated data and still represent significant business risk if the organization cannot deliver its product or service without that supplier.

That means a risk assessment may also need to consider availability, financial health, business continuity, service performance, legal exposure, and concentration risk.

If a vendor’s failure could materially interrupt the business, it belongs in the risk conversation even if an audit framework does not explicitly require it.

Can Automation Replace Third-Party Risk Analysis?

Automation can make TPRM substantially more efficient.

Technology can help inventory vendors, distribute questionnaires, collect evidence, monitor external indicators, schedule reassessments, track exceptions, and surface changes.

But those tools remain inputs into the process.

Human judgment is still required to determine whether information is relevant, understand business context, evaluate unusual answers, assess shared responsibility, and decide whether residual risk is acceptable.

What Should Organizations Do With Unacceptable Vendor Risk?

A mature TPRM program needs a defined response when residual risk remains above the organization’s tolerance.

Common options include:

• Accept: formally acknowledge and accept the remaining risk.
• Mitigate: work with the vendor or implement compensating controls.
• Transfer: shift portions of the financial or contractual exposure where appropriate.
• Avoid: stop or decline the relationship when the risk cannot be brought within tolerance.

The important part is that the organization makes the decision intentionally rather than allowing unresolved vendor risk to remain invisible.

How Can a Small TPRM Team Build a Mature Program?

Start smaller than you think you should.

Trying to build an enterprise-scale program immediately often creates processes the team cannot sustain.

“If you cannot operate 10 things well, you cannot operate 100 things well.”

— Cheri Hotman

Identify the handful of vendors that matter most. Establish a solid process around those relationships. Learn what works, improve it, and then scale.

A smaller program operated with integrity is more valuable than a massive program that exists mostly on paper.

What Should Organizations Do Now?

1. Inventory your vendors. Do not assume IT or procurement already has the complete picture.
2. Identify inherent risk. Start with sensitive data, system access, business criticality, operational dependency, and regulatory exposure.
3. Prioritize. Separate critical relationships from vendors that create little meaningful risk.
4. Match due diligence to risk. Use assurance reports, questionnaires, interviews, evidence, contractual protections, and deeper validation where appropriate.
5. Clarify shared responsibility. Document what the supplier does and what the organization remains responsible for.
6. Build the lifecycle. Include onboarding, ongoing monitoring, reassessment, performance review, and offboarding.
7. Monitor for triggers. Do not wait until the annual review when services, access, data, incidents, or external conditions materially change.
8. Define risk-response options. Know how the organization will accept, mitigate, transfer, or avoid unacceptable vendor risk.
9. Keep it sustainable. Build what the team can operate well today and mature it over time.

Frequently Asked Questions

What Is Third-Party Risk Management?

Third-party risk management is the process of identifying, assessing, mitigating, monitoring, and making decisions about the risks created by vendors, suppliers, service providers, partners, and other external relationships.

What Is Supply Chain Security?

Supply chain security focuses on managing security and business risk across the ecosystem of organizations, technologies, suppliers, and dependencies that support an organization’s products and services.

What Is the Difference Between Vendor Risk and Third-Party Risk?

The terms are often used interchangeably. Vendor risk commonly focuses on suppliers and service providers, while third-party risk can encompass a broader range of outside relationships. In practice, both should be evaluated through a risk-based process.

How Often Should Vendors Be Reassessed?

An annual review is a useful minimum, but vendors should also be reassessed when significant changes occur, such as new services, additional data access, security incidents, material changes in assurance reports, operational issues, or other events that alter the relationship’s risk.

Does Every Vendor Need a Security Questionnaire?

No. Due diligence should be proportionate to risk. A low-risk vendor may require minimal review, while a critical supplier may require questionnaires, assurance reports, evidence review, interviews, contractual protections, and ongoing monitoring.

Is a SOC 2 Report Enough for Third-Party Risk Management?

It depends on the vendor and the risk involved. A SOC 2 report can provide valuable assurance, but organizations still need to consider scope, exceptions, complementary customer controls, the specific service being used, and any risks not addressed by the report.

What Is Shared Responsibility in Cloud Security?

Shared responsibility defines which security activities the provider performs and which remain the customer’s responsibility. Even when using SaaS or cloud services, customers typically retain responsibilities related to access, configuration, data, identity, monitoring, or other controls.

How Can a Small TPRM Team Get Started?

Start by identifying the organization’s most important vendors, focusing on sensitive data, system access, and business criticality. Build a repeatable process around those relationships first, operate it well, and then mature and expand the program over time.

About This Session

This article is based on a Hotman Group live session on supply chain security, third-party risk management, and vendor risk, led by Cheri Hotman, Managing Partner of Hotman Group.

Cheri explains why vendor risk management needs to move beyond annual questionnaires and compliance-driven activity into a broader risk-management discipline that accounts for third parties, deeper supply-chain dependencies, inherent and residual risk, operational impact, shared responsibility, continuous monitoring, and the full vendor lifecycle.

The session also addresses practical questions about questionnaire design, vendor certifications, reassessment frequency, limited TPRM resources, critical-vendor oversight, and how organizations can build a sustainable program without trying to evaluate every supplier with the same level of rigor.

When to Bring in Hotman Group

Organizations often bring in Hotman Group when third-party risk management technically exists but has become difficult to operate, difficult to scale, or disconnected from actual risk. HG can help when:

• Vendor assessments are driven primarily by audit requirements rather than actual risk.
• The organization sends large questionnaires but lacks capacity to analyze and act on the responses.
• Nobody has a reliable inventory of vendors across the business.
• Vendor tiering does not consistently account for data, access, business criticality, or operational dependency.
• Critical vendors require deeper due diligence, shared-responsibility analysis, or ongoing oversight.
• The TPRM team is overwhelmed and needs to right-size the program around available resources.
• Offboarding, reassessment, monitoring, or vendor performance are inconsistent.
• Leadership needs a clearer picture of which third parties create the most meaningful risk and what should be done about it.

Hotman Group helps organizations build and mature risk-based third-party risk management programs that prioritize the vendors that matter most, clarify ownership and shared responsibility, strengthen due diligence, and create sustainable processes across the full vendor lifecycle.

Get an Outside View of Your Third-Party Risk Program

About Hotman Group

Hotman Group is a cybersecurity and Cyber GRC professional-services firm that helps organizations diagnose, design, build, remediate, implement, operate and mature cybersecurity programs. HG provides hands-on vCISO and vGRC leadership, supports multi-framework environments, and helps organizations select and implement GRC technology while connecting cybersecurity decisions to business risk and strategy.

Hotman Group works with organizations to improve third-party risk management, clarify vendor risk and ownership, strengthen due diligence, evaluate assurance, operationalize shared responsibility, and build sustainable governance processes across complex supplier ecosystems.

The goal is not to generate more questionnaires. It is to help organizations understand which vendors matter most, what risk they create, and what needs to happen to manage that risk responsibly.

Talk With Hotman Group