The Third-Party Risk Management Lifecycle for B2B Companies

Build Your Vendor Inventory Before You Assess Third-Party Risk

Pull vendor lists from accounts payable, contract management software, and single sign-on (SSO) logs from tools like Okta. Develop a centralized inventory of all vendors, contractors, SaaS providers, and data processors. A centralized vendor inventory creates a single source of truth, preventing your risk teams from missing third-party business relationships that sit elsewhere in the organization.

Your complete third-party vendor inventory must document four key details for every relationship:

• The third party's legal name and contact information.
• The specific service the third party provides.
• All company systems or data the third party is able to access.
• The name of the internal employee who owns the relationship.

Tier Third Parties by the Risk They Create

Tier each third-party vendor by scoring the exposure the relationship creates. Assign each vendor to a High, Medium, or Low risk tier by answering questions about its access to sensitive data, integration with critical systems, and your operational dependency on its service. A vendor that processes customer data, for example, carries a higher inherent risk than a vendor with limited access and no role in service delivery.

Focus your due diligence on the highest-risk relationships. Applying the same vendor risk assessment process to every third party wastes time on low-risk vendors and weakens focus on the relationships that matter most.

Define a specific assessment workflow for each risk level. The depth of evidence you require should rise with the tier.

Use your company's risk appetite to set the thresholds for each tier. Your risk tolerance policy should define the criteria for High, Medium, and Low risk vendors. Clear thresholds show when a vendor's inherent risk exceeds the level of exposure your organization has agreed to accept.

Use a Vendor Risk Assessment to Verify the Controls Behind Each Relationship

Once you have assigned a risk tier, assess the vendor against the specific risks its relationship creates. The purpose is not to collect as many documents as possible but to gather enough evidence to confirm that the vendor has controls that match the level of access, data exposure, and operational dependency involved.

For example, a high-risk vendor that stores customer data may need to show how it controls employee access, protects data, responds to security incidents, manages vulnerabilities, and monitors its own third parties. Evidence might include a SOC 2 report, ISO 27001 certificate, penetration test summary, security policies, or answers to a detailed questionnaire.

The assessment should answer one practical question: does the evidence support the level of trust your organization plans to place in this vendor?

Match the Assessment Depth to the Vendor's Risk Tier

The higher the risk a vendor creates, the more evidence you should require before approving the relationship. Low-risk vendors need enough review to confirm their limited exposure, while high-risk vendors need direct evidence that their security controls operate effectively.

• Low-Risk Vendors: Use a short questionnaire to confirm the assumptions behind the low-risk rating. Check that the vendor has limited access to company systems, does not handle sensitive data, and does not support a critical business service. Basic supporting evidence may be enough when the relationship creates little exposure.
• Medium-Risk Vendors: Use a more detailed questionnaire and request evidence for the controls most relevant to the relationship. Depending on the vendor, that may include security policies, access control documentation, incident response procedures, or an available SOC 2 or ISO 27001 report.
• High-Risk Vendors: Perform the deepest review because a control failure could create significant security, operational, or compliance exposure. Request direct evidence such as a SOC 2 Type II report, penetration test summary, incident response plan, access control documentation, and other evidence tied to the risks identified during tiering.

A certification or audit report strengthens the evidence, but it does not replace your own assessment. Your team still needs to confirm that the controls reviewed actually cover the systems, data, and services involved in your specific relationship with the vendor.

Assess Vendors Without Formal Certifications

A missing SOC 2 report or ISO 27001 certificate does not automatically make a vendor high risk or unsuitable. Smaller vendors and startups may have sound security controls before they invest in formal certification.

When formal assurance is unavailable, review the underlying evidence instead. Ask for documents and records that show how the vendor protects the systems and data involved in your relationship. Depending on the risk tier, that may include security policies, access control procedures, architecture diagrams, vulnerability management records, penetration test summaries, incident response procedures, or answers to a detailed security questionnaire.

The goal is to determine whether the vendor has appropriate controls for the access, data, and operational dependency involved. A certification makes that assessment easier, but the absence of one should lead to deeper evidence review rather than an automatic rejection.

Document the Evidence Behind Every Vendor Risk Decision

Every vendor approval, remediation requirement, and risk acceptance should be traceable back to the evidence that supported the decision.

Keep the vendor's questionnaire responses, supporting documents, risk score, identified findings, remediation actions, and final approval or risk acceptance together. Record missing evidence as well. An unanswered security question or expired SOC 2 report may be as important to the assessment as the documents the vendor provides.

The record should also show who reviewed the evidence, what decision they made, and why. If the organization accepts a known risk, document the reason, any compensating controls, and the conditions that would trigger another review.

Remediate Third-Party Risks Before You Accept Them

Every material finding needs a documented treatment decision before the vendor relationship proceeds. Your team should decide whether to require remediation, reduce the exposure with compensating controls, accept the remaining risk, or avoid the relationship altogether.

Start with remediation where the vendor needs to strengthen its own controls. A high-risk finding might require the vendor to restrict privileged access, fix a vulnerability, update an incident response process, or provide missing security evidence within an agreed timeframe.

Where the vendor cannot fully remove the weakness, your organization may reduce the exposure with compensating controls. For example, limiting API permissions to read-only access reduces the impact of weak write-access controls. Contract terms may also reduce risk by defining security obligations, breach notification requirements, data handling expectations, or remediation responsibilities.

Some risks remain after those measures. Assign a named owner before accepting any residual risk. The owner should understand the potential impact, the reason the business still wants to proceed, and the conditions that would make the decision unacceptable later.

Document the final decision alongside the vendor assessment. Record the finding, remediation or compensating controls, residual risk, approving owner, business justification, and any event that should trigger reassessment.

Risk acceptance should therefore be the end of the decision process, not the default response to a finding.

Monitor and Reassess Third-Party Risk When Conditions Change

Vendor risk changes as the relationship changes. A vendor may introduce a new subprocessor, lose a certification, experience a security incident, gain access to additional data, change its infrastructure, or become more important to your operations.

Monitor vendors for changes that could alter the original risk assessment. The depth of monitoring should follow the vendor's risk tier. High-risk vendors need closer oversight and more frequent evidence updates than vendors with limited access and low operational importance.

Define clear triggers for reassessment. A new data integration, expired SOC 2 report, material security incident, ownership change, new subprocessor, or expansion of system access may all justify another review.

Reassessment does not always mean repeating the entire original assessment. Focus on what changed. If a vendor gains access to additional customer data, review the controls protecting that data. If a compliance report expires, collect and assess the updated report. If a new dependency changes how critical the vendor is to your operations, revisit the vendor's impact and recovery requirements.

Keep the new evidence, findings, risk decisions, and reassessment history connected to the vendor record so the organization can see what changed and how it responded.

A material change may also move the vendor into a different tier. A low-risk vendor that later receives access to sensitive data or becomes critical to service delivery may need to move into a higher-risk tier and undergo a deeper assessment.

Offboard Vendors Securely When the Relationship Ends

Ending the contract does not automatically remove the security risk. Vendor offboarding should confirm that access has been revoked, integrations have been disconnected, and company data has been returned or securely deleted.

Start by removing every form of access created during the relationship. That may include user accounts, API keys, remote access permissions, shared credentials, service accounts, and system integrations.

The internal owner should confirm that the vendor no longer has access to company systems. Where the vendor holds company or customer data, review the contract to determine what must happen to that information when the relationship ends. The vendor may need to return the data, delete it, or provide evidence that destruction is complete.

Document each completed offboarding step. Record when access was removed, which integrations were disconnected, what happened to company data, and who confirmed completion.

A terminated contract is not proof that the risk has disappeared. The third-party relationship is only closed from a security perspective when the access, data, and dependencies created by that relationship have also been resolved.