Third-Party Software Assessment Checklist

1. Purpose

The Third-Party Software Assessment Checklist provides a structured method for evaluating software obtained from external vendors, suppliers, developers, open-source projects, or technology providers before and during its use within the organization.

The assessment helps determine whether third-party software introduces unacceptable:

Information-security risks
Vulnerability risks
Software supply-chain risks
Privacy risks
Data-protection risks
Availability risks
Licensing risks
Operational dependencies
Integration risks
Business continuity risks

The objective is to ensure that third-party software is evaluated according to its actual business, technical, security, and data impact.

2. Scope

This checklist may apply to:

Commercial software
SaaS applications
Open-source software
Third-party libraries
Frameworks
SDKs
APIs
Plugins
Extensions
Container images
Developer tools
Security tools
AI/ML software and models
Infrastructure-as-Code modules
CI/CD components
Software installed on production systems
Software with access to organizational information or systems

The level of assessment should be proportionate to risk.

3. Assessment Principle

The assessment should follow:

Business Need → Software Identification → Data & Access → Security Assessment → Vulnerability Review → Supplier/Source Assessment → Risk Assessment → Approval → Deployment → Monitoring → Reassessment → Secure Removal

The checklist is not intended to replace technical testing, supplier due diligence, vulnerability scanning, legal review, or risk assessment where those activities are required.

4. Assessment Information

Field	Details
Assessment ID
Software Name
Vendor/Maintainer
Version
Software Type
Business Owner
Technical Owner
Requesting Team
Intended Use
Environment	Development / Test / Production
Deployment Model	On-premise / Cloud / SaaS / Container
Assessment Date
Assessor
Risk Level	Low / Medium / High / Critical
Approval Status
Next Review Date

5. Business Need

Checklist

Business/technical requirement is documented
Purpose of the software is clearly defined
Existing approved alternatives were considered
The software is necessary for the intended purpose
Business owner is identified
Technical owner is identified
Expected users are identified
Critical business processes affected are identified

Evidence

Business request
Architecture document
Purchase request
Product evaluation
Business justification

6. Software Identification

Record:

Software name
Product/vendor
Version
Edition
Component type
Repository/source
Download location
Package manager
Deployment method
Operating system/platform
Dependencies
License

Verify that the software being assessed is the same software that will actually be deployed.

7. Vendor / Maintainer Assessment

Where applicable, evaluate:

Vendor identity
Vendor reputation
Supplier ownership
Company history
Support availability
Security contact
Security advisory process
Vulnerability disclosure process
Product lifecycle
Support lifecycle
End-of-life policy
Security-update commitment
Vendor dependency

For open-source software, consider:

Maintainer activity
Repository activity
Release frequency
Security advisories
Community support
Number and quality of maintainers
Project sustainability

8. Data Assessment

Determine whether the software:

Processes organizational information
Stores organizational information
Transmits organizational information
Processes customer information
Processes personal data
Processes confidential information
Processes restricted information
Processes authentication information
Processes financial information
Processes source code
Processes security information

Document:

Information Type: [ ]
Classification: [ ]
Data Location: [ ]
Retention: [ ]
Purpose: [ ]

9. Data Collection and Privacy

Where personal data is involved, assess:

What personal data is collected?
Why is it collected?
Where is it stored?
Who can access it?
Is the vendor a processor/service provider or another role under applicable law?
Are subprocessors used?
Where are subprocessors located?
How long is data retained?
How is data deleted?
Can data be exported?
Are international transfers involved?
Is a DPA required?
Are applicable privacy requirements addressed?

Privacy/legal review should be performed where required.

10. Access Assessment

Determine the access required by the software.

Access Types

No organizational-system access
User access
Application access
API access
Database access
Cloud access
Source-code access
Production access
Administrative access
Privileged access

Document:

Required Access:
Reason:
Users/Services:
Privilege Level:
Environment:

11. Authentication and Authorization

Verify, where applicable:

Individual accounts supported
SSO supported
MFA supported
Role-based access control available
Least privilege can be implemented
Privileged roles are restricted
Access can be reviewed
Access can be revoked
API credentials can be rotated
Service accounts can be controlled

Avoid unnecessary shared accounts.

12. Security Architecture

Assess whether the software provides appropriate security controls for its intended use.

Consider:

Authentication
Authorization
Encryption
Secure communications
Session management
Logging
Monitoring
Security configuration
Secrets management
Secure storage
Security boundaries
Administrative controls

For high-risk software, architecture review may be appropriate.

13. Vulnerability Assessment

Review:

Known vulnerabilities
Security advisories
CVEs, where applicable
Vendor security notices
Dependency vulnerabilities
Product security history
Patch availability
Vulnerability disclosure process
Remediation timelines

Record identified vulnerabilities:

ID	Vulnerability	Version	Severity	Exposure	Risk	Treatment	Status

14. Software Dependency Assessment

Determine whether the software contains or introduces additional dependencies.

Check:

Direct dependencies identified
Transitive dependencies considered
Third-party libraries identified
Container dependencies identified
Runtime dependencies identified
Build dependencies identified
CI/CD dependencies identified
Dependency vulnerabilities reviewed
Unsupported dependencies identified

Where appropriate, obtain or generate an SBOM.

15. Software Source and Provenance

Verify:

Software comes from an approved source
Vendor/repository is verified
Download location is trusted
Version is verified
Package integrity is verified where appropriate
Official release is used
Unapproved modified packages are not used

For open-source components, record the repository and approved version where appropriate.

16. Software Integrity and Supply Chain

Where relevant, assess:

Package signing
Code signing
Image signing
Hash verification
Trusted package repositories
Dependency locking
Protected source repositories
Secure build process
Release integrity
Software provenance

High-risk software should receive enhanced supply-chain review.

17. Secure Development Assessment

For software developed or maintained by a third party, consider:

Secure development lifecycle
Code review
Security testing
Vulnerability management
Static analysis
Dynamic testing
Dependency management
Release management
Security defect handling
Security incident process

Where appropriate, request evidence such as:

SOC 2 report
ISO 27001 certification
Penetration-test summary
Security assessment
Secure development documentation

Assurance evidence should be considered alongside the organization’s own risk assessment.

18. Security Testing

Determine whether testing is required.

Possible testing includes:

Vulnerability scanning
SAST
DAST
Software Composition Analysis
Container scanning
Penetration testing
Configuration assessment
Security architecture review

For SaaS applications, the organization may request relevant independent security-assurance evidence from the provider.

19. Encryption

Determine:

Is data encrypted in transit?
Is sensitive data encrypted at rest?
What encryption mechanisms are used?
Who manages encryption keys?
Can the organization control keys where necessary?
Are cryptographic configurations documented?
Are weak or obsolete protocols avoided?

Requirements should reflect information sensitivity and risk.

20. Logging and Monitoring

Assess whether relevant security events can be:

Logged
Monitored
Alerted
Exported
Retained
Investigated

Examples:

Login events
Failed authentication
Privilege changes
Administrative actions
Configuration changes
Data-access events
API activity
Security events

Determine whether logs can integrate with the organization’s monitoring/SIEM environment where necessary.

21. Security Incident Management

Assess whether the vendor/maintainer:

Has an incident-response process
Provides security contacts
Publishes security advisories
Notifies customers of relevant incidents
Provides incident information
Supports investigation
Provides remediation information

Where the software is critical, contractual incident-notification requirements may be appropriate.

22. Business Continuity and Availability

For business-critical software, assess:

Availability
Service dependencies
Backup
Recovery
Disaster recovery
Redundancy
Service-level commitments
Vendor continuity
Alternative arrangements
Data export capability

For SaaS, determine what happens if the provider becomes unavailable.

23. Integration Assessment

Identify integrations with:

Identity systems
Cloud environments
Databases
APIs
Production systems
Security tools
Customer systems
Payment systems
Source-code repositories

For each significant integration, identify:

System → Connection → Information → Authentication → Privilege → Risk

24. API and Credential Security

Where APIs are used:

Authentication method assessed
API keys protected
Tokens have appropriate expiration
Credentials can be rotated
Secrets are stored securely
Least privilege is applied
API activity can be monitored
Credentials are not stored in source code

Never record actual credentials or secrets in this checklist.

25. Cloud and SaaS Assessment

For cloud/SaaS software, evaluate:

Hosting provider
Data location
Security architecture
Identity controls
MFA
Encryption
Logging
Backup
Disaster recovery
Subprocessors
Security certifications
Incident management
Availability
Data deletion
Data export
Contractual security provisions

26. AI / Generative AI Software

Where AI/ML functionality is involved, assess:

What data is submitted to the AI system?
Is customer or personal data processed?
Is data used for model training?
Where is data stored?
Who operates the model?
What subprocessors are involved?
What model/API is being used?
How are prompts and outputs protected?
How are credentials protected?
What security testing exists?
What happens when the AI provider changes the model or service?

AI-related risks should be assessed according to the organization’s AI governance and information-security requirements.

27. Licensing and Legal Assessment

Where applicable, assess:

License type
Commercial terms
Open-source license
Usage restrictions
Distribution requirements
Attribution requirements
Intellectual-property considerations
Export or regulatory restrictions
Contractual restrictions

Legal review should be obtained where required.

28. Software Risk Assessment

The assessor should determine the overall software risk based on factors such as:

Business Impact

Critical business process
Customer-facing service
Revenue impact
Operational impact

Information Impact

Public
Internal
Confidential
Restricted
Personal data
Customer data

Technical Impact

Production access
Privileged access
Internet exposure
Integration with critical systems

Supplier Impact

Critical supplier
Single supplier
Limited alternatives
Vendor lock-in

Security Impact

Known vulnerabilities
Security history
Unsupported software
Supply-chain concerns

29. Risk Rating

An illustrative model:

Risk	Example
Low	Limited data, no privileged access, low business dependency
Medium	Internal/confidential information or meaningful integration
High	Production access, sensitive data, significant dependency
Critical	Privileged production access, critical business service, major security impact

The organization should use its approved risk methodology where one exists.

30. Findings and Remediation

Record findings using:

Finding ID	Area	Finding	Risk	Action	Owner	Due Date	Status

Possible treatments:

Remediate before deployment
Remediate after deployment
Apply compensating control
Restrict functionality
Restrict access
Replace software
Reject software
Accept residual risk

31. Approval Decision

The final assessment should document:

Assessment Outcome:

Approved
Approved with Conditions
Requires Remediation
Requires Risk Acceptance
Not Approved

The decision should be based on the organization’s documented risk criteria and approval authority.

32. Pre-Production Checklist

Before production deployment:

Assessment completed
Security findings reviewed
Critical vulnerabilities addressed
Required patches applied
Access configured
MFA enabled where applicable
Least privilege implemented
Logging enabled
Security configuration reviewed
Secrets securely configured
Backup/recovery requirements addressed
Contract/security agreement completed where required
Risk acceptance completed where required
Final approval obtained

33. Post-Deployment Monitoring

After deployment, monitor:

Security vulnerabilities
Vendor advisories
Version updates
Security incidents
Availability
Access
Configuration changes
Supplier changes
Subprocessors
End-of-life status
License changes

The software should be reassessed when material changes occur.

34. Reassessment Triggers

A reassessment should be considered when:

Major software version changes
New critical vulnerability
Major security incident
Significant architecture change
New sensitive data
New production access
New privileged access
New integration
Vendor ownership change
New subprocessors
Data-location change
Software becomes unsupported
Major licensing change
Significant business dependency change

35. AWS SaaS Startup Example

Suppose a SaaS startup wants to deploy a third-party customer-support application.

The software will process:

Customer names
Email addresses
Support tickets
Customer communications

It will integrate with the organization’s identity provider and customer-support workflow.

The assessment should therefore consider:

Business Need
→ Customer support platform required

Information
→ Customer and potentially personal data

Access
→ Support employees and administrators

Integration
→ SSO/API integration

Security
→ MFA, RBAC, encryption, logging

Supplier
→ SaaS provider and subprocessors

Risk
→ Unauthorized access or data exposure

Controls
→ SSO + MFA + least privilege + contractual requirements + monitoring

Approval
→ Business + IT/Security + Privacy/Legal where applicable

This produces a clear audit trail from business need through security approval.

36. Startup-Friendly Assessment Model

A startup can simplify the assessment using three levels.

Low Risk

Use when software:

Handles limited information
Has no production access
Has no privileged access
Has limited business impact

Perform basic:

Business assessment
Source/vendor check
Vulnerability review
License check
Approval

Medium Risk

Add:

Data assessment
Access assessment
Privacy review where applicable
Security architecture review
Dependency review
Vendor assurance
Contract review

High/Critical Risk

Add:

Detailed security assessment
Vulnerability/SCA testing
SBOM where appropriate
Penetration testing or independent assurance where appropriate
Detailed access review
Production-security review
BCP/DR assessment
Subprocessor review
Contractual security requirements
Formal risk treatment
Enhanced monitoring

37. Relationship With Other ISMS Documents

Document	Relationship
Software Dependency Inventory	Records software components
ICT Dependency Register	Records broader ICT dependencies
Supplier Register	Records software suppliers
Supplier Risk Assessment	Assesses supplier risk
Supplier Due Diligence	Assesses supplier before onboarding
Vulnerability Register	Tracks identified vulnerabilities
Asset Register	Records systems/assets
Application Register	Records applications
Secure Development Policy	Defines software-development security
Change Management	Controls software changes
Patch Management	Controls security updates
SBOM	Provides component-level visibility
Risk Register	Tracks significant software risks
Contract Security Review	Reviews supplier security obligations

38. Required Evidence

Depending on the software and risk, retain:

Completed assessment checklist
Vendor information
Security questionnaire
SOC 2/ISO 27001 evidence
Security architecture
Vulnerability scan
SCA report
SBOM
Penetration-test report/summary
Privacy assessment
DPA
Contract/security addendum
License review
Risk assessment
Risk acceptance
Approval record
Deployment record
Security configuration
Monitoring evidence

39. Common Mistakes

Mistake 1 — Only Checking Whether the Vendor Has ISO 27001

A certification can provide assurance, but it does not replace assessing whether the specific software is appropriate for the organization’s risk.

Mistake 2 — Ignoring Data

A software product with no sensitive data may have a very different risk profile from one processing customer or personal data.

Mistake 3 — Ignoring Privileged Access

Software with administrative or production access requires stronger assessment.

Mistake 4 — Assessing Only the Main Product

Dependencies, APIs, plugins, containers, and subprocessors can introduce additional risks.

Mistake 5 — Assessing Only Before Purchase

Security risk can change after deployment through vulnerabilities, new versions, new subprocessors, and vendor changes.

40. Quick Audit Checklist

An auditor may ask:

Do you assess third-party software before deployment?
How do you determine the assessment depth?
Do you identify the software version?
Do you know where the software came from?
What information does it process?
What access does it require?
Does it have privileged or production access?
How are vulnerabilities assessed?
How are dependencies identified?
Do you review unsupported software?
How are third-party APIs assessed?
How are SaaS providers assessed?
How are subprocessors considered?
How are security incidents handled?
How is software monitored after deployment?
What triggers reassessment?
Can you demonstrate approval for a production third-party application?

41. Final Audit Trail

A strong third-party software assessment should demonstrate:

Business Need
↓
Software Identified
↓
Vendor/Source Verified
↓
Data & Access Assessed
↓
Security Architecture Reviewed
↓
Dependencies & Vulnerabilities Checked
↓
Supplier/Privacy/License Risks Considered
↓
Risk Assessed
↓
Security Requirements Defined
↓
Findings Remediated
↓
Approval Obtained
↓
Software Deployed
↓
Security Monitored
↓
Reassessment When Required

Final Principle

Third-party software assessment is not simply a vendor questionnaire.

The key question is:

“What are we introducing into our environment, what can it access or affect, what risks does it introduce, and what evidence do we have that those risks are appropriately managed?”

The strongest approach connects the software → version → supplier/source → dependencies → data → access → vulnerabilities → risk → controls → approval → monitoring into one traceable lifecycle.

ISO/IEC 27001