Third-Party Due Diligence: Proven Checklist for 2026

HIPAA Compliance Checklist for 2025

‍

Third-party due diligence is not only limited to ensuring that the vendor passes the test on paper. The vendor may have good control practices despite the application having access to sensitive data, systems, or users.

According to the 2026 Verizon Data Breach Investigations Report, 48% of breaches involved third parties, up from 30% the year before.

Third party due diligence, therefore, becomes an effective risk assessment process and not just filling out questionnaires. It is important to know the vendor, what access the application has, the type of data that the vendor processes, and whether the exposure level is acceptable.

This guide will offer a step-by-step guide for evaluating vendors, verifying facts, prioritizing evaluations based on risks, and taking action against underperforming vendors.

‍

1. What Is Third-Party Due Diligence?

Third-party due diligence is the process of evaluating a vendor, supplier, or third-party application before and during a business relationship to identify security, privacy, financial, legal, and operational risks.

It helps organizations verify who they are working with, understand the exposure involved, and decide whether to approve, restrict, remediate, or reject the relationship.

‍

Security Starts With Every App

One gap is enough.

Get The Checklist

‍

2. Third-Party Vendor Due Diligence Checklist: 10 Checks to Complete

A strong due diligence process should tell you more than whether a vendor has the right certifications. It should show where the relationship creates exposure, how serious that exposure is, and what controls are needed before approval.

A. Verify the Vendor and Its Ownership

Start by establishing exactly who you are doing business with. A vendor's brand name may not match the legal entity holding the contract or processing your data.

Check:

Legal entity, parent company, and ownership structure
Registered business locations and operating regions
Financial and corporate standing
Key contacts and accountable business owner
Any acquisitions, ownership changes, or related entities

This matters because ownership and organizational changes can affect where data is processed, who provides the service, and which contracts or security commitments apply.

B. Confirm the Business Purpose and Criticality

Do not assess a vendor without understanding why your organization needs it. The same application can carry very different risks depending on how it is used.

Document:

Business process supported
Number and type of users
Data involved
Systems it needs to connect with
Impact if the service becomes unavailable
Whether a replacement exists

A vendor supporting payroll, customer data, or production operations deserves more scrutiny than a low-impact internal tool.

C. Review Vendor and Application Security

Security should be assessed at both the vendor and application level. A vendor may have mature security controls while the application still creates excessive access or integration risk.

Look for:

SOC 2, ISO 27001, penetration test reports, or equivalent evidence
Encryption in transit and at rest
MFA and SSO support
Vulnerability and patch management
Security incident response procedures
Audit logging and monitoring
Application permissions and available security controls
API and integration security

Do not stop at a SOC 2 report or questionnaire. Check whether the application's security controls, access model, and configuration fit your environment. This distinction becomes especially important when teams have dozens or hundreds of SaaS applications to review.

‍

Secure Your SaaS Stack Step By Step

One checklist. Every critical control.

Access The Guide

‍

D. Check Data Handling and Privacy

Find out what happens to your data from the moment it enters the application until it is deleted.

Focus on:

Types of data collected and processed
Data storage and processing locations
Retention and deletion practices
Encryption and backup controls
Data ownership and portability
Cross-border data transfers
Privacy obligations and applicable regulations
Subprocessors handling your information

Then connect the data review to actual application usage. Knowing that a vendor can process sensitive data is different from knowing that employees are actually uploading or sharing it.

E. Review User and Privileged Access

Vendor access can expand quietly after onboarding. New employees join, administrators change roles, and permissions accumulate.

Review:

Who has access to the application
Admin and privileged accounts
SSO and MFA enforcement
Role-based access controls
User provisioning and deprovisioning
Access review frequency
External or vendor-managed accounts
Dormant and unnecessary accounts

CloudEagle can add value at this point by bringing application access and identity data into the same view, making it easier to identify excessive, inactive, or unnecessary access across the SaaS environment.

F. Identify Integrations and Non-Human Identities

An application rarely operates alone. It may connect to your identity provider, CRM, cloud environment, databases, or security tools.

Map:

APIs and OAuth connections
Service accounts
API keys and access tokens
Bots and automation accounts
Connected applications
Permissions granted to each integration
Owner and revocation process for each identity

A vendor can introduce several non-human identities (NHIs) into your environment. These may continue to hold access even when the original employee, project, or business need is gone.

This is particularly important for SaaS and AI tools or applications, where integrations can create additional identities and access paths that are easy to overlook.

G. Review Compliance and Legal Obligations

SaaS Compliance should be tied to the actual relationship, not treated as a certification-collection exercise.

Review:

Applicable laws and industry requirements
Data processing agreements
Security and breach notification clauses
Audit and assessment rights
Data ownership terms
Liability and indemnification
Regulatory responsibilities
Contractual security requirements

The key is to verify that the vendor's stated compliance scope actually covers the product, data, geography, and service your organization is buying.

H. Assess Business Continuity and Resilience

A vendor can have strong security and still become a major business risk if its service fails.

Evaluate:

Business continuity plans
Disaster recovery capabilities
Backup strategy
Recovery time and recovery point objectives
History of major outages
Dependency on critical subcontractors
Communication and escalation procedures

For business-critical vendors, identify a fallback before onboarding. Knowing how you will operate without the vendor is part of knowing how much risk you are accepting.

I. Review Financial and Commercial Health

Security is only one part of vendor risk. A financially unstable or commercially restrictive vendor can create operational problems later.

Check:

Financial stability
Contract length and renewal terms
Pricing and usage limits
Service-level commitments
Unexpected cost triggers
Dependency on a single provider
Vendor concentration risk

Also compare business value against exposure. A vendor with high access, high spend, and low actual usage may deserve a very different decision from a business-critical platform.

J. Check Subprocessors and Exit Conditions

Your risk does not necessarily stop with the vendor. Cloud providers, data processors, hosting companies, and other fourth parties may also touch your data or support the service.

Review:

Current subprocessors and their locations
Changes to the subprocessor list
Critical fourth-party dependencies
Notification requirements for new subprocessors
Data deletion and return procedures
Contract termination terms
Access and credential revocation
API and integration shutdown
Transition or migration support

Due diligence should answer two questions: What are we trusting this vendor with, and how cleanly can we walk away?

‍

3. What Evidence Should You Request From a Third Party?

A questionnaire tells you what a vendor says about its controls. Evidence helps you check whether those claims hold up. The documents you request should match the vendor’s risk and the access or data involved.

For most vendors, request evidence that is relevant, such as:

Security: Reports about SOC 2 and/or ISO 27001, penetration testing, vulnerability management, and incident response information
Privacy: DPA, data retention policies, where data is processed, and subprocessors
Access: SSO, MFA, privileged access controls, and user access policies
Resilience: Business continuity plans, disaster recovery testing, and recovery objectives
Compliance: Any relevant certifications, audit reports, and attestations to regulations
Commercial: Insurance, SLAs, security responsibilities, and key contract provisions

Do not accept any document simply because it is available. Make sure that the document is current and relevant to your system and application. One product certification does not certify another product.

The goal is not the accumulation of documents, but the collection of enough evidence for making a proper risk assessment decision.

‍

4. What Should You Do If a Vendor Fails Due Diligence?

Not all failed due diligence reviews mean that you need to disqualify the vendor. Instead, first analyze the problem found, its severity, and if any risk reduction measures are available.

The steps are going to differ based on the result:

Critical security or privacy risk: Temporarily halt onboarding or grant limited access until the issue is fixed.
Too much access: Eliminate unnecessary users, permissions, integrations, or elevated accounts.
Missing controls or documentation: Request a remediation plan that includes an owner and deadline. Don’t assume that a lack of evidence is a pass.
Uncontrolled identities: Verify if the vendor has any other identities besides the people, such as service accounts, API keys, and tokens.
High-risk but critical vendor: Implement compensating controls and note the exception and approval date.
Risk that is not manageable: Replace the vendor or prepare for their exit.

The final decision should be straightforward: remediate the risk, restrict the relationship, formally accept the risk, or walk away. The decision, evidence, and owner should all be documented.

‍

5. How Should You Perform Due Diligence on SaaS and AI Applications?

A SaaS or AI tool can look harmless until it gets plugged into your business systems. That is where the real questions start. What data does it see? What can it do? And who or what can act through it?

Before approving the application, check:

Data: What data goes in, where is it stored, and how is it deleted?
Access: What can users, admins, APIs, and OAuth connections reach?
Integrations: Which systems are connected, and what can those connections actually do?
AI use: Are prompts, files, or customer data stored, shared, or used for training?
Non-human identities: Are API keys, tokens, service accounts, or agents created?
Real usage: Are employees using the tool the way it was approved?
Exit: Can you cut access, disconnect integrations, and remove data completely?

Keep the vendor and application separate in your review. For example, Anthropic is the vendor. Claude is the application. The vendor may have strong controls, but the way Claude is connected and used inside your company creates a separate risk.

CloudEagle.ai helps teams bring application discovery, access, usage, security posture, and non-human identities into one view, making it easier to spot exposure that a vendor questionnaire may not reveal.

The real question is not just whether the vendor is secure. It is what the application can access inside your business.

‍

6. How Should Third-Party Due Diligence Continue After Onboarding?

Due diligence should not end when the vendor contract is signed. A vendor’s risk can change as its product, access, integrations, or role in your business changes.

You do not need to repeat the full assessment every month. Instead, set clear triggers for a fresh review:

New integrations or wider system access
More sensitive data being shared
Changes in users, admins, or permissions
New subprocessors or major product changes
Security incidents or control failures
Changes in ownership, financial health, or business criticality
Renewal, expansion, or significant contract changes

For SaaS and AI applications, also compare approved use with actual use. A tool that was low-risk at onboarding may become much more important once more teams, data, or systems depend on it.

The point is simple: do not review vendors just because the calendar says it is time. Review them when something changes the risk.

‍

7. How Does CloudEagle Support Third-Party Vendor Due Diligence?

A vendor questionnaire gives you the vendor’s side of the story. The harder part is seeing what that vendor or application actually exposes inside your environment.

CloudEagle.ai connects SaaS and AI application discovery with access, security posture, usage, spend, and non-human identities. This helps teams move beyond static vendor responses and answer practical questions:

Which third-party applications are actually in use?
Who has access, and is that access still justified?
What APIs, tokens, service accounts, or AI agents are connected?
Is the application creating more exposure than the original review identified?
Should the vendor be remediated, restricted, renewed, or replaced?

Real-World Example: Armorcode

Armorcode used CloudEagle.ai to improve visibility into non-human identities from 40% to 95%, remediate 480 unmanaged identities, and optimize 220+ over-privileged identities.

For third-party due diligence, the lesson is clear: passing a questionnaire does not mean the relationship is risk-free. You also need to see the access, identities, and connections created by the application after it enters your environment.

‍

Know Your Vendors Before You Trust Them

CloudEagle.ai helps you evaluate vendor risk with centralized governance and procurement.

See How CloudEagle Works

Book a Demo

‍

8. Conclusion

The due diligence process should be more than just confirming that the vendor seems secure on paper; it should be about discovering exactly what the vendor and applications can see, handle, and expose.

The purpose of this is straightforward: to validate the facts, determine the risk, and make an informed decision prior to it becoming a business issue.

See Where Your Third-Party Risk Stands

Get a clearer view of your applications, access, identities, and security gaps with CloudEagle.

Book a Demo

9. FAQs

1. What is included in third-party due diligence?‍

Due diligence for third parties usually considers the security, privacy, compliance, financial, operational, accessibility, and reputational issues of the vendor. The level of investigation must be related to the risk that the vendor or application represents.

2. What is the difference between third-party due diligence and TPRM?‍

Vendor due diligence is an essential component of Third Party Risk Management (TPRM), which typically involves assessment of the vendor and onboarding, renewal, and risk decisions. TPRM is a wider process that continues over the lifecycle of the relationship including monitoring, remediation, access reviews, and exit.

3. How often should third-party due diligence be performed?‍

There is no one-size-fits-all calendar for all vendors. More intensive scrutiny must be done in case of high-risk vendor relationships, whereas others might just have a less intense calendar. Reviews also need to be conducted when certain activities happen, such as increased data access, integrations, security events, transfer of ownership, and changes in business use.

4. What evidence should you ask a vendor for during due diligence?‍

Ask for any supporting evidence for those risks identified, which can include SOC 2 reports, ISO 27001 compliance reports, penetration test results, data processing agreements (DPAs), subprocessor listings, incident response procedures, and business continuity plans. Consider the date, scope, and relevance of that evidence, and not all certifications indicate low risk.

5. How is due diligence different for SaaS and AI vendors? ‍

It is necessary to go beyond the internal control structures of the company when performing due diligence on SaaS and AI solutions. You must also evaluate application permissions, data flow, integration capabilities, user permissions, AI data management, API keys, and any other non-human identity-related items. In the case of AI applications, the use of the model, prompt, and file management, training data, and automation may be important too.

‍