Best Practices for Third-Party Risk Management

Jeff Hudgens
Updated: Oct. 27, 2025
Read Time: 3 mins.

In this article:
What third party risk management is (and why it matters)
Key steps in building a third party risk management framework
Questions to ask vendors (and when to push back)
Red flags to watch for in vendor assessments
Why cloud-based vendors deserve special attention
Best practices for running a continuous TPRM program

No matter how tight your defenses are, your security is only as strong as your weakest vendor. A breach at a partner can quickly become your breach. That’s why third party risk management (TPRM) has become a must-have—not a nice-to-have—for organizations of every size.

Think of it this way: you lock your front door at night, but if your neighbor leaves theirs wide open and you share a hallway, you’re still exposed. That’s what makes third party vendor risk management such a critical part of any security strategy.

What Is Third Party Risk Management?

At its core, third party risk management (sometimes called TPRM, 3rd party risk management or vendor risk management) is the process of identifying, assessing, and monitoring the security practices of the vendors, contractors and partners you rely on.

More than just compliance checkboxes, vendor risk management about protecting sensitive data, ensuring business continuity and reducing your exposure to risks introduced by outsiders.

Step 1: Identify and Prioritize Critical Vendors

Not every vendor poses the same risk. Start by building a list of your IT vendors and the services they provide. Flag vendors as “critical” if they:

Access your systems or network
Handle sensitive data like PII or PHI
Play a role in business continuity or system availability

Once identified, rank them by potential impact. Those at the top should be first in line for assessments.

Step 2: Assess with Reports and Questionnaires

If a vendor has undergone third party audits, ask for the reports. These can save time and give you unbiased insights. Commonly requested documents include:

SOC 2® Report (Type I or II)
ISO 27001 certification
PCI DSS attestation of compliance
HITRUST certification
Public-facing penetration test reports (this article helps explain what to look for in a quality penetration test)

For vendors without these, use a custom questionnaire. Ask about encryption, vulnerability scans, incident response programs and access controls. Don’t be afraid to get specific—your data depends on it.

Questions to Ask Your Partners

In addition to the reports above, you may decide that vendors should complete a custom security questionnaire created by your company. Common questions on these questionnaires include:

How do you encrypt data?
How often do you perform vulnerability scans and penetration tests?
What identity and access management policies/tools do you use?
How do you secure your physical facility?
Have you ever suffered a data breach? What happened?

Step 3: Review Responses (and Stay Skeptical)

Collecting reports isn’t the finish line. Someone qualified needs to review them. Here’s a great article on analyzing and assessing these reports.

Watch out for:

Vague answers that dodge the question
Vendors claiming “we don’t need a SOC 2®” when they actually do
Vendors pointing to their cloud provider’s certifications (AWS, Azure, etc.) as proof of their own security

Cloud hosting doesn’t automatically mean secure. Misconfigured workloads and weak internal practices are still on the vendor.

Step 4: Track and Monitor Continuously

One thing risk management can’t be is one-and-done. Build a TPRM process that tracks vendor gaps and requires remediation plans when issues are uncovered. Reassess your most critical vendors annually (at minimum).

Think of it as a living program—a third party risk management framework that evolves as vendors change, threats evolve and your business grows.

Special Concerns About Cloud Environments
You should be especially vigilant about responses from vendors that provide solutions based on a cloud-vendor’s infrastructure. Many organizations don’t fully understand the shared responsibilities inherent to working with cloud providers.
Vendors need to understand that your risk assessment includes their controls, not just the controls at the cloud provider. For example, a vendor may just say, “Our hosting provider is AWS, and they have a SOC 2®.” That’s not good enough. While the cloud provider’s controls are certainly relevant, they don’t cover all of your concerns. We have seen plenty of vendors using insecure workloads because of misconfiguration or other issues.
This problem may even pop up when you ask about physical security. The vendor may dodge this question by stating, “We are not allowed access to AWS datacenters.” That’s probably true. But to assess the vendor’s risk posture, you need to know about the physical security controls employed at the vendor’s facilities.