1. Purpose
The Supplier Contract Review Checklist is used to verify that appropriate business, information-security, privacy, operational, legal, and supplier-management requirements are addressed before a supplier contract is approved or renewed.
The checklist helps confirm that the contract clearly establishes:
- What the supplier will provide
- What information the supplier can access
- Security responsibilities
- Privacy and data-processing obligations
- Access requirements
- Incident notification
- Subprocessor requirements
- Business continuity expectations
- Security assurance
- Audit and assessment rights
- Data retention, return, and deletion
- Service termination and offboarding
- Responsibility for security and compliance obligations
Core Principle
Supplier → Service → Information → Risk → Security Requirements → Contract → Approval → Monitoring → Review → Offboarding
2. When to Use This Checklist
Use the checklist:
- Before signing a new supplier contract
- Before onboarding a supplier
- During contract renewal
- When contract scope changes
- When the supplier receives new types of information
- When supplier access changes
- When production or privileged access is introduced
- When personal data processing is introduced
- When new subprocessors are introduced
- When the supplier becomes critical to business operations
- After a major security or privacy incident
- When applicable legal or regulatory requirements change
3. Contract Review Information
| Field | Details |
|---|---|
| Contract Review ID | |
| Supplier ID | |
| Supplier Name | |
| Service/Product | |
| Business Owner | |
| Supplier Owner | |
| Department | |
| Contract Type | MSA / SOW / SaaS / Professional Services / Other |
| Contract Version | |
| Review Date | |
| Contract Start Date | |
| Contract End Date | |
| Renewal Date | |
| Supplier Criticality | Low / Medium / High / Critical |
| Supplier Risk | Low / Medium / High / Critical |
| Personal Data Involved | Yes / No |
| Production Access | Yes / No |
| Privileged Access | Yes / No |
| Review Status | Draft / In Review / Approved / Changes Required |
4. Contract Documents Reviewed
Identify all documents forming part of the supplier relationship.
| Document | Available | Reviewed | Version/Date |
|---|---|---|---|
| Master Service Agreement | ☐ | ☐ | |
| Statement of Work | ☐ | ☐ | |
| Order Form | ☐ | ☐ | |
| Data Processing Agreement | ☐ | ☐ | |
| Supplier Security Addendum | ☐ | ☐ | |
| SLA | ☐ | ☐ | |
| Privacy Terms | ☐ | ☐ | |
| Acceptable Use Terms | ☐ | ☐ | |
| Security Requirements | ☐ | ☐ | |
| Other | ☐ | ☐ |
Confirm that documents do not contain conflicting security or privacy obligations.
5. Business and Service Scope
| # | Review Item | Yes/No/N/A | Comments |
|---|---|---|---|
| 1 | Supplier legal entity is correctly identified | ||
| 2 | Service description is clear | ||
| 3 | Business purpose is documented | ||
| 4 | Deliverables are defined | ||
| 5 | Service responsibilities are defined | ||
| 6 | Organization responsibilities are defined | ||
| 7 | Service-level requirements are documented | ||
| 8 | Dependencies are understood | ||
| 9 | Service locations are identified where relevant | ||
| 10 | Critical business processes supported by the supplier are identified |
6. Information Security Obligations
Verify that the supplier has contractual obligations to protect information appropriate to the service and risk.
- ☐ Information-security requirements are documented
- ☐ Supplier must maintain appropriate security controls
- ☐ Security responsibilities are clearly allocated
- ☐ Security requirements apply to relevant personnel
- ☐ Security requirements apply throughout the contract
- ☐ Security obligations continue where appropriate after termination
- ☐ Material security changes are addressed
7. Confidentiality
Verify that confidentiality obligations are clearly defined.
| Review Item | Yes/No/N/A |
|---|---|
| Confidential information is defined | |
| Supplier use of confidential information is restricted | |
| Access is limited to authorized personnel | |
| Personnel are subject to confidentiality obligations | |
| Confidentiality survives termination where appropriate | |
| Disclosure to third parties is controlled | |
| Legal/regulatory disclosure requirements are addressed |
8. Information Classification and Handling
Verify that the contract addresses appropriate handling of information.
- ☐ Information classification requirements are identified
- ☐ Supplier handling requirements are defined
- ☐ Storage requirements are defined where necessary
- ☐ Information transfer requirements are defined
- ☐ Copying/exporting restrictions are addressed
- ☐ Secure disposal requirements are addressed
- ☐ Sensitive information handling is addressed
9. Access Control
Where supplier personnel access organizational systems or information:
| Review Item | Yes/No/N/A |
|---|---|
| Access is limited to business need | |
| Least privilege is required | |
| Individual accounts are required where appropriate | |
| Shared accounts are restricted | |
| Access approval is required | |
| Access is periodically reviewed | |
| Access is revoked when no longer required | |
| Remote access is appropriately controlled |
10. Authentication and MFA
Verify that the contract or applicable security requirements address authentication.
- ☐ Strong authentication requirements defined
- ☐ MFA required for privileged access where appropriate
- ☐ MFA required for remote/system access where appropriate
- ☐ Authentication exceptions are controlled
- ☐ Credential-sharing is prohibited or controlled
- ☐ Authentication requirements apply to relevant subcontractors
11. Privileged Access
For suppliers with administrative or production access:
- ☐ Privileged access is explicitly identified
- ☐ Privileged access requires authorization
- ☐ Access is limited to named personnel where appropriate
- ☐ Privileged access is monitored/logged
- ☐ Privileged access is periodically reviewed
- ☐ Temporary access is removed after use
- ☐ Emergency access is controlled
- ☐ Privileged access is revoked at termination
12. Data Protection and Privacy
Where personal data is processed:
- ☐ Data-processing roles are identified
- ☐ Processing purposes are defined
- ☐ Categories of personal data are identified
- ☐ Categories of data subjects are identified
- ☐ Processing duration is defined
- ☐ Processing instructions are established
- ☐ Security measures are defined
- ☐ Data-subject rights assistance is addressed
- ☐ Privacy incidents are addressed
- ☐ Data deletion/return is addressed
- ☐ Appropriate DPA is executed where required
13. Customer Data
Where the supplier handles customer information:
- ☐ Customer information is clearly identified
- ☐ Permitted use is defined
- ☐ Unauthorized secondary use is restricted
- ☐ Customer-data security requirements are defined
- ☐ Customer-data breach obligations are defined
- ☐ Customer-data return/deletion is addressed
- ☐ Subprocessor access is controlled
14. Security Incident Requirements
Verify that the supplier must notify the organization about relevant security incidents.
| Requirement | Yes/No/N/A |
|---|---|
| Security incidents are defined/addressed | |
| Notification obligation is documented | |
| Notification contact is identified | |
| Notification timeframe is defined | |
| Minimum incident information is specified | |
| Investigation support is required | |
| Evidence preservation is addressed | |
| Containment/remediation cooperation is required | |
| Post-incident reporting is addressed |
The contractual timeframe should be aligned with the organization’s regulatory and business requirements rather than using an arbitrary period.
15. Data Breach Requirements
Where personal data is involved:
- ☐ Personal-data breach obligations are defined
- ☐ Supplier must notify the organization appropriately
- ☐ Breach investigation responsibilities are defined
- ☐ Regulatory notification responsibilities are allocated
- ☐ Customer notification responsibilities are clarified
- ☐ Evidence preservation is addressed
- ☐ Corrective actions are required where appropriate
- ☐ Post-breach review is addressed
16. Vulnerability Management
Verify that the supplier has appropriate vulnerability-management obligations.
- ☐ Vulnerability identification is required
- ☐ Critical vulnerabilities receive appropriate priority
- ☐ Security patches are applied within defined expectations
- ☐ Vulnerability remediation is tracked
- ☐ Material vulnerabilities are communicated where relevant
- ☐ Security exceptions are controlled
- ☐ Vulnerability evidence can be requested where appropriate
17. Application and Secure Development
Where the supplier develops or maintains software:
- ☐ Secure development practices are required
- ☐ Code-review requirements are addressed
- ☐ Security testing is addressed
- ☐ Dependency management is addressed
- ☐ Vulnerability remediation is addressed
- ☐ Development and production environments are appropriately separated
- ☐ Security requirements apply to software changes
- ☐ Source-code access is appropriately controlled
18. Encryption
Verify that appropriate encryption requirements are established.
- ☐ Data in transit protection
- ☐ Data at rest protection
- ☐ Sensitive data encryption
- ☐ Key management
- ☐ Cryptographic controls
- ☐ Exceptions and alternative controls
Requirements should reflect the sensitivity of information and applicable risk.
19. Logging and Monitoring
Where relevant:
- ☐ Security events are logged
- ☐ Administrative activities are logged
- ☐ Access to sensitive information is monitored
- ☐ Logs are protected
- ☐ Security alerts are investigated
- ☐ Log retention requirements are defined where necessary
- ☐ Relevant logs can be provided during investigations
20. Security Assurance and Certifications
Verify whether the supplier provides appropriate assurance.
| Evidence | Available | Reviewed | Valid Until |
|---|---|---|---|
| ISO 27001 Certificate | ☐ | ☐ | |
| SOC 2 Report | ☐ | ☐ | |
| Penetration Test | ☐ | ☐ | |
| Independent Assessment | ☐ | ☐ | |
| Security Questionnaire | ☐ | ☐ | |
| Other | ☐ | ☐ |
A certification or assurance report should support—not replace—the supplier-specific risk assessment.
21. Audit and Assessment Rights
Where appropriate, verify that the organization has reasonable mechanisms to obtain assurance.
- ☐ Security information can be requested
- ☐ Relevant audit reports can be requested
- ☐ Independent assurance reports can be reviewed
- ☐ Security questionnaires can be completed
- ☐ Assessments can be conducted where justified
- ☐ Material findings can be communicated
- ☐ Corrective actions can be requested
- ☐ Regulatory/customer assurance requirements can be supported
Audit rights should be proportionate to supplier risk and practical contractual constraints.
22. Subcontractors and Subprocessors
Verify contractual controls over subcontractors.
| Requirement | Yes/No/N/A |
|---|---|
| Subcontractor use is permitted/controlled | |
| Subprocessors are identified where required | |
| Prior approval or notification mechanism is defined | |
| Security requirements flow down | |
| Privacy requirements flow down | |
| Material changes are communicated | |
| Supplier remains accountable for contracted obligations | |
| Organization can assess material subprocessor risk |
23. Data Location and International Transfers
Where relevant:
- ☐ Processing locations identified
- ☐ Storage locations identified
- ☐ Support-access locations identified
- ☐ International transfers identified
- ☐ Applicable transfer mechanism addressed
- ☐ Data localization requirements considered
- ☐ Changes to relevant locations are controlled
24. Business Continuity and Disaster Recovery
For important services:
- ☐ Business continuity requirements defined
- ☐ Recovery requirements defined
- ☐ Recovery objectives addressed where necessary
- ☐ Backup requirements addressed
- ☐ Disaster recovery arrangements addressed
- ☐ Continuity testing addressed
- ☐ Material disruptions must be communicated
- ☐ Alternative arrangements are considered for critical services
25. Service Availability and SLA
Verify that the contract defines appropriate service commitments.
| Review Item | Details |
|---|---|
| Availability requirement | |
| SLA | |
| Support hours | |
| Critical incident response | |
| Recovery expectations | |
| Planned maintenance | |
| Service credits/remedies | |
| Escalation process |
Security requirements should not be separated from availability and continuity where the service is business-critical.
26. AI and Generative AI
Where the supplier uses AI/ML or generative AI:
- ☐ AI use is disclosed
- ☐ Customer data use is defined
- ☐ Data used for model training is addressed
- ☐ AI subprocessors are identified
- ☐ AI data retention is addressed
- ☐ Confidential information submitted to AI systems is controlled
- ☐ Personal-data processing through AI is addressed
- ☐ Material AI-service changes are communicated
- ☐ Security/privacy requirements apply to AI processing
27. Security Change Notification
Verify that the supplier is required to communicate material changes where appropriate.
Potential changes include:
- New subprocessors
- Ownership changes
- Major service architecture changes
- Data-location changes
- New processing activities
- Security incidents
- Material security-control changes
- Significant service changes
- Changes affecting compliance obligations
28. Regulatory and Compliance Requirements
Review whether the supplier contract addresses relevant obligations.
- ☐ Applicable laws identified
- ☐ Regulatory obligations considered
- ☐ Sector-specific requirements considered
- ☐ Customer contractual requirements considered
- ☐ Privacy obligations addressed
- ☐ Security obligations addressed
- ☐ Cooperation with regulatory inquiries addressed where appropriate
29. Security Responsibilities Matrix
Document responsibility allocation.
| Security Area | Organization | Supplier | Shared |
|---|---|---|---|
| Access Management | ☐ | ☐ | ☐ |
| MFA | ☐ | ☐ | ☐ |
| Encryption | ☐ | ☐ | ☐ |
| Vulnerability Management | ☐ | ☐ | ☐ |
| Incident Management | ☐ | ☐ | ☐ |
| Backup | ☐ | ☐ | ☐ |
| BCP/DR | ☐ | ☐ | ☐ |
| Privacy | ☐ | ☐ | ☐ |
| Subprocessors | ☐ | ☐ | ☐ |
| Logging | ☐ | ☐ | ☐ |
| Security Testing | ☐ | ☐ | ☐ |
| Data Deletion | ☐ | ☐ | ☐ |
Avoid leaving responsibility ambiguous for critical security activities.
30. Security Requirements During Service Changes
Verify that the contract addresses security when the service changes.
Examples:
- New functionality
- New integrations
- New data types
- New access levels
- New hosting location
- New subprocessors
- New AI capabilities
- New production environments
Material changes should trigger appropriate security and privacy reassessment.
31. Data Retention
Verify that the contract addresses data retention.
- ☐ Retention requirements defined
- ☐ Retention is linked to the agreed purpose
- ☐ Legal retention requirements considered
- ☐ Backup retention considered
- ☐ Temporary copies addressed where relevant
- ☐ Data beyond the agreed retention period is controlled
32. Data Return and Deletion
At contract termination or when information is no longer required:
- ☐ Data return requirements defined
- ☐ Data deletion requirements defined
- ☐ Deletion timeframe defined where appropriate
- ☐ Backup copies addressed
- ☐ Subprocessor deletion addressed
- ☐ Deletion confirmation available where appropriate
- ☐ Legal retention exceptions addressed
33. Supplier Offboarding
Verify that the contract supports secure termination.
- ☐ Supplier access must be revoked
- ☐ Organizational information must be returned/deleted
- ☐ Credentials/tokens must be revoked
- ☐ Supplier assets must be returned where applicable
- ☐ Technical connections must be removed
- ☐ Subprocessor access must be terminated
- ☐ Confidentiality obligations continue where appropriate
- ☐ Security obligations after termination are defined
- ☐ Critical-service migration/exit arrangements are addressed
34. Security Incident Investigation After Termination
Where appropriate, verify that contractual obligations allow cooperation after termination for:
- Open investigations
- Security incidents
- Data breaches
- Regulatory inquiries
- Evidence preservation
- Data recovery
- Legal obligations
35. Insurance and Liability
Where relevant, review:
- ☐ Cyber insurance
- ☐ Professional liability insurance
- ☐ General liability
- ☐ Data-breach liability
- ☐ Indemnification
- ☐ Liability limitations
- ☐ Contractual allocation of security/privacy risk
These provisions should be reviewed by the organization’s legal/contract authority.
36. Security Exceptions
Document any security requirement that the supplier cannot meet.
| Exception ID | Requirement | Supplier Limitation | Risk | Compensating Control | Approval |
|---|---|---|---|---|---|
| EX-001 | |||||
| EX-002 |
An exception should have an identified owner, rationale, risk assessment, compensating controls where applicable, and appropriate approval.
37. Contract Security Findings
Record issues identified during the review.
| Finding ID | Contract Section | Finding | Risk | Required Change | Owner | Status |
|---|---|---|---|---|---|---|
| CSF-001 | ||||||
| CSF-002 |
38. Final Contract Review
Before approval, confirm:
- ☐ Contract scope is understood
- ☐ Supplier risk assessment is completed
- ☐ Supplier due diligence is completed
- ☐ Security requirements are addressed
- ☐ Privacy requirements are addressed
- ☐ DPA completed where required
- ☐ Subprocessors reviewed
- ☐ Data locations reviewed
- ☐ Incident requirements reviewed
- ☐ BCP/DR requirements reviewed
- ☐ Audit/assurance requirements reviewed
- ☐ Data return/deletion requirements reviewed
- ☐ Offboarding requirements reviewed
- ☐ Exceptions documented
- ☐ Contract findings resolved or accepted
- ☐ Appropriate approvals obtained
39. Contract Approval
| Role | Name | Decision | Date | Comments |
|---|---|---|---|---|
| Business Owner | Approved / Rejected | |||
| Supplier Owner | Approved / Rejected | |||
| Information Security | Approved / Rejected | |||
| Privacy | Approved / Rejected | |||
| Legal | Approved / Rejected | |||
| Risk Owner | Approved / Rejected |
Approval should follow the organization’s authority and risk-approval requirements.
40. Contract Execution Checklist
Before the contract becomes effective:
- ☐ Final contract version approved
- ☐ Security clauses incorporated
- ☐ DPA executed where applicable
- ☐ Security addendum executed where applicable
- ☐ SLA finalized
- ☐ Required approvals obtained
- ☐ Signatures completed
- ☐ Effective date confirmed
- ☐ Contract stored in approved repository
- ☐ Supplier Register updated
- ☐ Critical Supplier Register updated where applicable
- ☐ Monitoring requirements recorded
- ☐ Contract renewal date recorded
41. Post-Contract Monitoring
Contract approval is not the end of supplier security management.
Monitor, as appropriate:
- Security incidents
- Data breaches
- Supplier security reviews
- Certifications
- Security assessments
- Access
- Subprocessors
- Data locations
- Service availability
- Security findings
- Contract changes
- Business continuity
- Risk changes
42. Startup-Friendly Contract Model
The depth of contract review should be proportionate to supplier risk.
Low Risk
Focus on:
Confidentiality → Basic Security → Incident Notification → Data Handling → Termination
Medium Risk
Add:
Access Control → MFA → Data Protection → Security Assurance → Subprocessors → Backup → Security Review
High/Critical Risk
Add:
Privileged Access → Production Security → Security Testing → Detailed Incident Requirements → BCP/DR → Audit/Assessment Rights → Enhanced Assurance → Subprocessor Controls → Data Transfer → Exit/Migration → Enhanced Monitoring
This allows a startup to apply stronger contractual controls where the supplier presents greater risk.
43. Relationship With Other ISMS Documents
| Document | Purpose |
|---|---|
| Supplier Register | Maintains supplier population |
| Supplier Risk Assessment | Determines supplier risk |
| Supplier Due Diligence Questionnaire | Collects supplier information |
| Supplier Security Requirements | Defines expected controls |
| Supplier Contract Security Checklist | Reviews contract security provisions |
| Supplier Security Addendum | Establishes detailed security obligations |
| DPA Checklist | Reviews privacy/data-processing terms |
| Supplier Onboarding Checklist | Controls secure onboarding |
| Supplier Security Review | Periodically reassesses supplier |
| Supplier Access Review | Reviews supplier access |
| Supplier Offboarding Checklist | Controls secure termination |
| Risk Register | Tracks significant organizational risks |
44. ISO 27001 Connection
Supplier contract review supports the organization’s broader ISMS processes, including areas related to:
- Supplier relationships
- Security requirements in supplier agreements
- ICT supply-chain security
- Access control
- Information transfer
- Protection of information
- Incident management
- Business continuity
- Privacy and protection of personal information
- Risk treatment
- Supplier monitoring and review
The Supplier Contract Review Checklist is an organizational tool, not a universally mandatory ISO 27001 document. The organization should determine the appropriate contractual requirements based on its risk assessment, supplier criticality, information handled, access provided, contractual commitments, and applicable legal/regulatory requirements.
45. Quick Audit Checklist
An auditor should be able to verify:
- ☐ Supplier identified
- ☐ Service scope documented
- ☐ Contract documents identified
- ☐ Supplier risk assessed
- ☐ Information handled identified
- ☐ Security responsibilities defined
- ☐ Confidentiality addressed
- ☐ Access controls addressed
- ☐ MFA addressed where appropriate
- ☐ Privileged access addressed
- ☐ Privacy/DPA addressed where applicable
- ☐ Incident notification addressed
- ☐ Data breach requirements addressed
- ☐ Vulnerability management addressed
- ☐ Encryption addressed
- ☐ Logging/monitoring addressed
- ☐ Subprocessors addressed
- ☐ Data location addressed
- ☐ BCP/DR addressed
- ☐ Security assurance addressed
- ☐ Audit/assessment rights addressed
- ☐ Data retention addressed
- ☐ Data return/deletion addressed
- ☐ Offboarding addressed
- ☐ Security exceptions documented
- ☐ Contract findings tracked
- ☐ Required approvals obtained
- ☐ Final executed contract retained
- ☐ Supplier monitoring requirements established
46. Final Audit Trail
A strong supplier contract review should establish the following chain:
Supplier → Service → Information → Access → Risk → Security Requirements → Contract Clauses → Privacy/DPA → Approval → Contract Execution → Onboarding → Monitoring → Review → Change Management → Offboarding
Final Principle
A supplier contract should do more than define commercial terms. Where the supplier introduces information-security, privacy, technology, or operational risk, the contract should clearly establish the responsibilities, controls, notification requirements, assurance mechanisms, and end-of-relationship obligations needed to manage that risk.
The contract review should therefore connect the supplier’s actual risk profile to the security and privacy obligations that are contractually enforceable and operationally monitored.