Third-Party Due Diligence Checklist

1. Purpose

The Third-Party Due Diligence Checklist provides a structured process for evaluating a supplier, vendor, contractor, consultant, service provider, partner, or other external organization before entering into a business relationship.

The objective is to determine whether the third party:

Is legitimate and suitable for the proposed relationship
Can meet business requirements
Introduces information-security, privacy, operational, legal, or compliance risks
Has appropriate security controls
Can protect organizational and customer information
Can meet contractual requirements
Can support business continuity requirements
Can securely manage access and information
Has appropriate exit and data-disposal arrangements

Core Principle

Identify → Verify → Understand the Service → Assess Risk → Review Controls → Approve → Monitor → Reassess

2. When to Use

Use this checklist before engaging a third party where the relationship may involve:

Organizational information
Customer information
Personal data
Confidential or Restricted information
Access to systems
Cloud infrastructure
Production environments
Source code
Databases
Security systems
Physical facilities
Critical business processes
Outsourced operations
Regulatory or contractual obligations

It may also be used during periodic reassessment or when a material change occurs.

3. Third-Party Information

Field	Details
Due Diligence ID
Third-Party ID
Legal Name
Trading Name
Website
Service/Product
Third-Party Type
Business Owner
Supplier Owner
Proposed Start Date
Contract Period
Business Purpose
Countries of Operation
Primary Contact
Security Contact
Assessment Date
Reviewer
Assessment Status

4. Third-Party Type

Select the applicable category:

☐ Supplier
☐ Vendor
☐ SaaS Provider
☐ Cloud Provider
☐ IT Service Provider
☐ Managed Service Provider
☐ Consultant
☐ Contractor
☐ Development Partner
☐ Security Provider
☐ Auditor
☐ Certification Provider
☐ Payment Provider
☐ Data Processor
☐ Business Partner
☐ Outsourced Service Provider
☐ Other: __________________

5. Business Need Assessment

Before assessing security, establish why the third party is required.

☐ Business requirement identified
☐ Service clearly defined
☐ Business owner identified
☐ Alternatives considered where appropriate
☐ Criticality assessed
☐ Dependency understood
☐ Expected duration defined
☐ Expected information/system access defined

Business Justification

6. Service Assessment

Document what the third party will actually provide.

Question	Response
What service is provided?
Which business process does it support?
Is the service customer-facing?
Is it business-critical?
What systems are involved?
What information is involved?
What happens if the service becomes unavailable?
Are alternatives available?

7. Third-Party Legitimacy and Identity Verification

Verify the third party before entering into the relationship.

☐ Legal entity verified
☐ Registration details verified where applicable
☐ Business address verified
☐ Website/domain verified
☐ Business contacts verified
☐ Ownership information considered where relevant
☐ Service offering verified
☐ References considered where appropriate
☐ Contracting entity confirmed

Evidence

8. Ownership and Management

Where relevant, understand:

☐ Legal ownership
☐ Parent organization
☐ Subsidiaries
☐ Major ownership changes
☐ Relevant acquisitions
☐ Key management
☐ Organizational structure

The level of investigation should be proportionate to the risk and nature of the relationship.

9. Financial and Business Stability

For critical or high-risk relationships, consider:

☐ Financial stability
☐ Business continuity
☐ Dependency on key customers
☐ Significant litigation or disputes where relevant
☐ Major organizational changes
☐ Business viability
☐ Ability to continue providing the service

Assessment

10. Information Security Governance

Assess whether the third party has an established information-security program.

☐ Information-security policy
☐ Security roles and responsibilities
☐ Security governance
☐ Risk-management process
☐ Security objectives
☐ Security awareness program
☐ Security incident process
☐ Internal security reviews
☐ Security management accountability

Evidence

11. Security Certifications and Assurance

Determine whether the third party has relevant independent assurance.

☐ ISO/IEC 27001
☐ SOC 1
☐ SOC 2
☐ PCI DSS
☐ ISO/IEC 27701
☐ ISO/IEC 42001
☐ Independent penetration test
☐ Independent security assessment
☐ Other: __________________

For each assurance document, verify:

Scope
Covered service
Covered locations
Validity period
Exceptions
Relevant controls

Important

A certificate or assurance report should not automatically be treated as evidence that all of the organization’s requirements are satisfied.

12. Security Risk Assessment

Determine the third party’s risk exposure.

Consider:

Information

☐ Customer data
☐ Personal data
☐ Financial data
☐ Confidential information
☐ Restricted information
☐ Source code
☐ Security information

Access

☐ Corporate access
☐ SaaS access
☐ Cloud access
☐ Production access
☐ Database access
☐ Source-code access
☐ Privileged access

Business

☐ Critical business process
☐ Customer-facing service
☐ High availability dependency
☐ Limited alternatives
☐ Difficult migration

Technology

☐ API integration
☐ Cloud dependency
☐ Network connectivity
☐ Identity integration
☐ Software integration

13. Information Classification Assessment

Identify the highest classification involved.

☐ Public
☐ Internal
☐ Confidential
☐ Restricted

Information Involved

Classification Rationale

14. Personal Data and Privacy

Determine whether the third party processes personal data.

☐ Personal data involved
☐ No personal data
☐ Assessment required

If personal data is involved, assess:

☐ Processing purpose
☐ Data categories
☐ Data subjects
☐ Processing locations
☐ Data retention
☐ Data deletion
☐ Subprocessors
☐ International transfers
☐ Privacy/security requirements
☐ Data-processing agreement where applicable
☐ Incident/breach notification

15. Customer Data

If customer information is involved:

☐ Customer data identified
☐ Customer contractual requirements reviewed
☐ Data minimization considered
☐ Access restrictions defined
☐ Encryption requirements considered
☐ Transfer method approved
☐ Retention defined
☐ Deletion/return defined

16. Access Requirements

Document exactly what access the third party requires.

System	Environment	Access	Privileged	Start	Expiry

Avoid approving broad access such as “full access” unless it is genuinely necessary and appropriately controlled.

17. Authentication and MFA

Verify:

☐ Named user accounts
☐ Individual accountability
☐ MFA
☐ Strong authentication
☐ SSO where appropriate
☐ Privileged authentication controls
☐ Temporary access where appropriate
☐ Access expiry
☐ Session controls
☐ Authentication logging

18. Privileged Access

If privileged access is required:

☐ Business justification documented
☐ Specific permissions identified
☐ Internal approval obtained
☐ Named individual accounts used
☐ MFA enabled
☐ Access limited to required systems
☐ Logging enabled where appropriate
☐ Periodic review defined
☐ Expiry defined where practical
☐ Revocation process defined

19. Cloud Security

If the third party provides or manages cloud services:

☐ Cloud provider identified
☐ Cloud accounts/subscriptions identified
☐ Production environments identified
☐ IAM controls assessed
☐ MFA assessed
☐ Network controls assessed
☐ Encryption assessed
☐ Logging assessed
☐ Monitoring assessed
☐ Backup assessed
☐ Security configuration assessed
☐ Privileged access assessed

20. Application Security

For software or SaaS providers:

☐ Secure development process
☐ Secure coding practices
☐ Code review
☐ Dependency management
☐ SAST/DAST where appropriate
☐ Vulnerability management
☐ Penetration testing
☐ Security defect management
☐ Software release controls
☐ Security testing before significant releases

21. Vulnerability Management

Assess whether the third party:

☐ Identifies vulnerabilities
☐ Performs vulnerability scanning
☐ Performs security testing
☐ Prioritizes vulnerabilities
☐ Remediates vulnerabilities
☐ Tracks remediation
☐ Performs retesting
☐ Communicates significant vulnerabilities
☐ Has emergency vulnerability procedures

22. Endpoint and Malware Protection

Where relevant:

☐ Endpoint protection
☐ Supported operating systems
☐ Security patches
☐ Device encryption
☐ Malware protection
☐ Device management
☐ Secure configuration
☐ Remote-wipe capability where appropriate

23. Network Security

Assess relevant controls:

☐ Network segmentation
☐ Firewalls
☐ Secure remote access
☐ VPN
☐ Network monitoring
☐ Intrusion detection/prevention where appropriate
☐ Secure administration
☐ Network access restrictions

24. Encryption

Determine whether appropriate encryption is used.

☐ Encryption in transit
☐ Encryption at rest
☐ Key management
☐ Key access controls
☐ Key rotation
☐ Certificate management
☐ Secure cryptographic mechanisms

25. Secrets and Credential Management

Assess whether the third party securely manages:

Passwords
API keys
Tokens
Database credentials
Cloud credentials
SSH keys
Certificates
Encryption keys

☐ Secure secrets storage
☐ No credentials stored in source code
☐ Access restriction
☐ Rotation
☐ Revocation
☐ Monitoring
☐ Compromise response

26. Logging and Monitoring

Assess whether appropriate security events are logged and monitored.

☐ Authentication events
☐ Privileged activity
☐ Administrative activity
☐ Security events
☐ System events
☐ Application events
☐ Access events
☐ Incident alerts
☐ Log protection
☐ Log retention

27. Security Incident Management

Verify:

☐ Incident response plan
☐ Security incident procedure
☐ Incident escalation
☐ Security contact
☐ Evidence preservation
☐ Investigation process
☐ Corrective action
☐ Lessons learned

Supplier Notification Requirement

☐ Defined in contract
☐ Defined in security agreement
☐ Other: __________________

28. Data Breach Management

If personal/customer data is involved:

☐ Breach response procedure
☐ Breach detection
☐ Breach assessment
☐ Notification process
☐ Customer communication
☐ Regulatory assessment
☐ Evidence preservation
☐ Investigation cooperation

29. Business Continuity

Assess:

☐ Business Continuity Plan
☐ Disaster Recovery Plan
☐ Backup
☐ Recovery testing
☐ Redundancy
☐ Recovery objectives
☐ Incident escalation
☐ Alternative arrangements

Recovery Information

RTO: __________________

RPO: __________________

Recovery Evidence: __________________

30. Service Availability

Assess:

☐ SLA defined
☐ Availability requirement defined
☐ Monitoring
☐ Incident escalation
☐ Service outage notification
☐ Service recovery process

31. Supplier Personnel Security

Where relevant:

☐ Background verification
☐ Employment checks
☐ Confidentiality agreements
☐ Security responsibilities
☐ Security awareness
☐ Role-based training
☐ Access restrictions
☐ Offboarding process

The exact checks should reflect applicable law and the risk of the role.

32. Subcontractors and Subprocessors

Determine whether the third party uses other organizations.

☐ Subcontractors identified
☐ Subprocessors identified
☐ Services identified
☐ Data/access identified
☐ Locations identified
☐ Security requirements flow down
☐ Incident requirements flow down
☐ Approval/change notification requirements defined

33. Data Location

Record where information will be:

Stored
Processed
Backed up
Transferred

Location	Activity	Data	Applicable Requirement

Consider applicable contractual, privacy, regulatory, and customer requirements.

34. Information Transfer

Assess how information will be exchanged.

☐ Approved transfer channel
☐ Encryption
☐ Recipient verification
☐ Access restrictions
☐ Secure file sharing
☐ API security
☐ Transfer logging where appropriate
☐ Data minimization
☐ Receipt confirmation

35. Physical Security

Where relevant:

☐ Physical access controls
☐ Visitor management
☐ CCTV/security monitoring
☐ Secure areas
☐ Environmental protection
☐ Equipment protection
☐ Media protection
☐ Secure disposal

36. AI and Generative AI

If the third party uses AI systems in delivering the service, assess:

☐ AI use identified
☐ Data used by AI identified
☐ Customer data restrictions
☐ Personal-data restrictions
☐ Model/provider identified
☐ Data retention understood
☐ Training/use of submitted data understood
☐ Human review
☐ AI security controls
☐ AI subprocessors identified
☐ Contractual restrictions where required

37. Regulatory and Legal Requirements

Identify applicable requirements based on:

Jurisdiction
Industry
Information processed
Customer requirements
Contractual obligations
Services provided
Data subjects
Regulatory environment

☐ Applicability assessed
☐ Requirements documented
☐ Responsibility assigned
☐ Evidence identified

38. Contract Review

Before approval, verify that relevant contractual requirements are addressed.

☐ Service description
☐ Security requirements
☐ Confidentiality
☐ Information protection
☐ Access restrictions
☐ Incident notification
☐ Data breach notification
☐ Subprocessors
☐ Data location
☐ Data retention
☐ Data deletion/return
☐ Business continuity
☐ Security assurance
☐ Termination
☐ Exit assistance where appropriate

39. Supplier Security Questionnaire

Where appropriate:

☐ Questionnaire required
☐ Questionnaire issued
☐ Questionnaire completed
☐ Responses reviewed
☐ Evidence requested
☐ Gaps identified
☐ Follow-up questions completed

The questionnaire should be proportionate to the third party’s risk.

40. Evidence Review

Review relevant evidence such as:

☐ ISO certificate
☐ SOC report
☐ Penetration-test summary
☐ Security assessment
☐ Vulnerability assessment
☐ Business continuity evidence
☐ Disaster recovery test
☐ Security policies
☐ Privacy documentation
☐ Data-processing agreement
☐ Security architecture
☐ Incident process
☐ Other: __________________

Do not request or retain unnecessary sensitive credentials or secret values as due-diligence evidence.

41. Security Findings

Record identified gaps.

Finding ID	Area	Finding	Risk	Action	Owner	Due Date

42. Risk Treatment

For each significant finding, determine the appropriate treatment.

Possible approaches include:

Reduce
Avoid
Share/Transfer
Accept

Treatment Record

Risk	Treatment	Control/Action	Owner	Due Date	Status

Risk acceptance should follow the organization’s defined risk-acceptance process.

43. Third-Party Risk Rating

Use the organization’s approved risk methodology.

Example:

Risk Level	Typical Considerations
Low	Limited information/access and low business impact
Medium	Important service or moderate information exposure
High	Sensitive information, production access, or significant dependency
Critical	Critical business service, highly sensitive information, or major dependency

These categories are examples and should be aligned with the organization’s risk methodology.

44. Approval Decision

Assessment Result

☐ Approved
☐ Approved with Conditions
☐ Further Information Required
☐ Remediation Required Before Approval
☐ Risk Acceptance Required
☐ Not Approved

Conditions

Approver

Name: ______________________

Role: ______________________

Date: ______________________

45. Contract Before Onboarding

Before the third party receives access or information, verify:

☐ Contract executed
☐ NDA executed where required
☐ DPA completed where applicable
☐ Security requirements agreed
☐ Required risk approval completed
☐ Access approved
☐ Supplier owner assigned
☐ Security contact recorded

46. Third-Party Onboarding

After approval:

☐ Supplier added to Supplier Register
☐ Risk assessment completed
☐ Contract recorded
☐ Security requirements recorded
☐ User access approved
☐ MFA configured where required
☐ Access limited to required scope
☐ Information-sharing method approved
☐ Monitoring established
☐ Review date established

47. Periodic Due Diligence

Reassess third parties according to risk.

Review:

☐ Service changes
☐ Business criticality
☐ Information processed
☐ Access rights
☐ Security incidents
☐ Security assurance
☐ Vulnerabilities
☐ Subprocessors
☐ Data locations
☐ Contract changes
☐ Business continuity
☐ Regulatory changes
☐ Open findings

48. Reassessment Triggers

A new or accelerated review may be required following:

☐ Major security incident
☐ Data breach
☐ Major vulnerability
☐ New production access
☐ New privileged access
☐ New customer data
☐ New personal data
☐ New subprocessor
☐ Change in ownership
☐ Acquisition/merger
☐ New geographic location
☐ Major service change
☐ Significant outage
☐ Regulatory change
☐ Contract change

Process

Change → Assess Impact → Reassess Risk → Update Controls → Approve → Record

49. Third-Party Offboarding

When the relationship ends:

☐ Access identified
☐ User accounts disabled
☐ Privileged access revoked
☐ Cloud access removed
☐ VPN access removed
☐ SaaS access removed
☐ API credentials/tokens addressed
☐ Organizational information returned/deleted where required
☐ Assets returned
☐ Subprocessor access addressed
☐ Secrets rotated where necessary
☐ Exit evidence retained
☐ Supplier Register updated

Exit Principle

Revoke → Return/Delete → Verify → Record → Close

50. Final Due Diligence Summary

Area	Result	Finding
Business
Supplier Legitimacy
Information Security
Privacy
Access Control
Cloud Security
Application Security
Incident Management
Business Continuity
Subprocessors
Contract
Regulatory
Overall Risk

51. Due Diligence Approval Record

Third Party: ______________________________

Assessment ID: ____________________________

Overall Risk: ______________________________

Assessment Result: _________________________

Conditions: ________________________________

Business Owner: ____________________________

Security Reviewer: __________________________

Risk Owner: ________________________________

Approver: __________________________________

Approval Date: _____________________________

Next Review Date: __________________________

52. Audit Evidence

The organization should retain appropriate evidence such as:

Completed due-diligence checklist
Supplier questionnaire
Security assessment
Risk assessment
Security certifications
Assurance reports
Contracts
NDA/DPA
Security agreement
Access approvals
Supplier Register entry
Findings
Corrective actions
Risk acceptance
Periodic review records
Incident records
Exit records

The evidence retained should be proportionate to the risk and should not unnecessarily contain passwords, API keys, private keys, authentication secrets, or other credentials.

53. AWS SaaS Startup Example

A SaaS startup wants to engage a third-party VAPT provider.

Due Diligence

Business Need: Annual application and infrastructure security testing.

Information: Application architecture, test credentials, vulnerability information.

Classification: Confidential/Restricted depending on the information.

Access: Temporary testing access.

Risk: Medium/High depending on scope.

Required Controls

NDA/SOW
Named tester accounts
MFA
Limited scope
Temporary access
No unnecessary production access
Defined testing window
Evidence handling requirements
Secure report delivery
Incident escalation
Access revocation after testing

Audit Trail

Business Need → Due Diligence → Security Assessment → Risk Assessment → Contract → Approval → Temporary Access → Testing → Secure Report → Access Revocation → Review

54. Startup-Friendly Due Diligence Model

Not every third party requires the same level of investigation.

Low Risk

Focus on:

Business purpose
Supplier identity
Information involved
Basic security
Contract
Risk
Approval

Medium Risk

Add:

Security questionnaire
MFA
Encryption
Vulnerability management
Incident management
Backup/continuity
Security assurance

High/Critical Risk

Add enhanced assessment of:

Privileged access
Production access
Cloud security
Application security
Security testing
Subprocessors
Data location
Privacy
Business continuity
Independent assurance
Contractual security requirements
Exit/migration capability

This risk-based approach prevents the organization from treating a low-risk office supplier and a production cloud provider as if they present the same level of risk.

55. Common Mistakes

Avoid:

Approving suppliers based only on price.
Treating procurement approval as security approval.
Sending the same questionnaire to every supplier without considering risk.
Failing to identify information being shared.
Failing to identify production or privileged access.
Accepting certifications without reviewing scope.
Ignoring subcontractors/subprocessors.
Ignoring data location.
Ignoring business continuity.
Failing to define incident notification.
Granting access before due diligence is completed.
Not documenting risk acceptance.
Not reassessing suppliers after major changes.
Not planning for supplier exit.

56. Relationship With Other ISMS Documents

Document	Relationship
Supplier Register	Records the supplier
Critical Supplier Register	Identifies critical suppliers
Supplier Security Management Policy	Defines governance requirements
Supplier Risk Assessment	Evaluates supplier risk
Supplier Security Questionnaire	Collects supplier security information
Supplier Security Assessment	Evaluates supplier controls
Supplier Security Agreement	Defines contractual security requirements
Third-Party Access Procedure	Controls supplier access
Supplier Access Review	Reviews ongoing access
Information Transfer Procedure	Controls information sharing
Business Continuity Plan	Addresses critical supplier dependencies
Supplier Offboarding	Controls supplier exit
Risk Register	Tracks significant risks
Incident Management	Handles supplier incidents

57. ISO 27001 Connection

Third-party due diligence supports the organization’s risk-based management of supplier relationships and related areas such as:

Supplier relationships
Supplier agreements
ICT supply-chain security
Information security risk management
Access control
Information transfer
Incident management
Business continuity
Information protection

The Third-Party Due Diligence Checklist is not itself a universally mandatory ISO 27001 form. The organization should determine the appropriate due-diligence activities and records based on its risks, supplier relationships, business requirements, contractual obligations, and applicable legal/regulatory requirements.

The applicable ISO 27001 controls should be determined through the organization’s risk assessment and Statement of Applicability.

58. Quick Audit Checklist

☐ Business need documented
☐ Third party verified
☐ Service understood
☐ Criticality assessed
☐ Information identified
☐ Classification identified
☐ Personal data assessed
☐ Access requirements identified
☐ Privileged access assessed
☐ Security controls assessed
☐ Security assurance reviewed
☐ Subprocessors assessed
☐ Data locations assessed
☐ Incident requirements defined
☐ Business continuity assessed
☐ Contract reviewed
☐ Security requirements included
☐ Risk assessed
☐ Findings documented
☐ Risk treatment defined
☐ Approval obtained
☐ Supplier Register updated
☐ Monitoring established
☐ Review date defined
☐ Exit requirements considered

59. Final Audit Trail

For every significant third-party relationship, the organization should be able to demonstrate:

Why do we need this third party?
Who are they?
What service do they provide?
What information will they access?
What systems will they access?
What risks do they introduce?
What security controls do they have?
What evidence supports their controls?
What contractual requirements apply?
Who approved the relationship?
How will the relationship be monitored?
What happens if the supplier has a security incident?
What happens when the relationship ends?

Final Principle

Third-party due diligence is not simply a questionnaire exercise. It is a structured decision process that connects the business need, supplier, information, access, security controls, risk, contract, approval, monitoring, and exit arrangements into one defensible audit trail.