ISO/IEC 27001

⌘K
  1. Home
  2. Docs
  3. ISO/IEC 27001
  4. Other Doc
  5. Supplier Offboarding Checklist

Supplier Offboarding Checklist

1. Purpose

The Supplier Onboarding Checklist is used to ensure that a supplier, vendor, contractor, consultant, technology provider, or service provider is properly evaluated, approved, contracted, and securely onboarded before services begin.

The checklist helps ensure that:

  • The supplier has an approved business purpose.
  • Required due diligence has been completed.
  • Supplier security and privacy risks have been assessed.
  • Required contracts and security clauses are in place.
  • Access is granted only where necessary.
  • Information is shared according to its classification.
  • Security requirements are communicated and acknowledged.
  • Critical suppliers have appropriate continuity and exit arrangements.
  • Onboarding activities are supported by auditable evidence.

Important: This checklist is a practical implementation template. Not every item will apply to every supplier. The extent of onboarding should be based on supplier criticality, information handled, access required, regulatory/contractual requirements, and risk.


2. Supplier Onboarding Principle

Business Need → Supplier Identification → Due Diligence → Risk Assessment → Security Review → Approval → Contract → Access & Information Setup → Security Validation → Go-Live → Monitoring

A supplier should not be considered fully onboarded merely because a purchase order or commercial agreement has been signed.


3. Supplier Onboarding Information

FieldDetails
Supplier ID
Supplier Name
Supplier Type
Service / Product
Business Owner
Supplier Owner
Department
Supplier CriticalityLow / Medium / High / Critical
Information ClassificationPublic / Internal / Confidential / Restricted
Personal Data InvolvedYes / No
Customer Data InvolvedYes / No
Production Access RequiredYes / No
Privileged Access RequiredYes / No
Cloud ServiceYes / No
Contract Start Date
Planned Go-Live Date
Supplier Risk Rating
Onboarding Status

4. Business Need and Service Validation

Checklist

  • Business need has been documented.
  • Required service/product has been clearly defined.
  • Business owner has been identified.
  • Service scope has been documented.
  • Expected deliverables have been defined.
  • Service-level requirements have been identified.
  • Availability requirements have been considered.
  • Business dependency has been assessed.
  • Alternative suppliers or contingency arrangements have been considered where appropriate.
  • Supplier criticality has been determined.

Evidence

Examples:

  • Business justification
  • Purchase request
  • Statement of Work
  • Service description
  • Requirements document
  • Approval record

5. Supplier Due Diligence

Confirm that the required supplier due diligence has been completed.

  • Supplier identity verified.
  • Legal entity information verified.
  • Ownership/management information reviewed where relevant.
  • Business legitimacy verified.
  • Relevant financial/business stability information reviewed.
  • Security capabilities assessed.
  • Privacy requirements assessed.
  • Regulatory requirements assessed.
  • Relevant certifications/assurance reports reviewed.
  • Security questionnaire completed where required.
  • Supplier references reviewed where appropriate.
  • Subcontractors/subprocessors identified.
  • Data locations identified.
  • Supplier risk assessment completed.

Related document: Third-Party Due Diligence Checklist


6. Supplier Risk Assessment

  • Supplier risk assessment completed.
  • Information handled identified.
  • Access requirements identified.
  • Business criticality assessed.
  • Security dependency assessed.
  • Privacy risk assessed.
  • Regulatory/contractual risk assessed.
  • Availability/continuity risk assessed.
  • Supply-chain dependency considered.
  • Concentration risk considered where relevant.
  • Initial risk rating assigned.
  • Risk treatment determined.
  • Residual risk documented.
  • Risk owner identified.
  • Risk acceptance obtained where required.

7. Security Requirements

Determine which security requirements apply to the supplier.

  • Information security requirements defined.
  • Information classification requirements defined.
  • Access-control requirements defined.
  • MFA requirements defined.
  • Privileged access requirements defined.
  • Encryption requirements defined.
  • Logging/monitoring requirements defined.
  • Vulnerability management requirements defined.
  • Incident notification requirements defined.
  • Data breach notification requirements defined.
  • Backup/recovery requirements defined.
  • Business continuity requirements defined.
  • Secure information-transfer requirements defined.
  • Data retention requirements defined.
  • Data disposal requirements defined.
  • Subprocessor requirements defined.
  • Security testing requirements defined where applicable.

8. Contract and Legal Review

Before onboarding, confirm that appropriate contractual documentation is complete.

  • Master Service Agreement / contract completed.
  • Statement of Work completed where applicable.
  • NDA completed where required.
  • Data Processing Agreement completed where required.
  • Security requirements incorporated.
  • Confidentiality obligations defined.
  • Information protection obligations defined.
  • Access-control requirements defined.
  • Incident notification requirements defined.
  • Data breach notification requirements defined.
  • Subprocessor requirements defined.
  • Data location requirements addressed.
  • Audit/assurance rights addressed where appropriate.
  • Business continuity requirements addressed where relevant.
  • Data return/deletion requirements defined.
  • Contract termination requirements defined.
  • Security obligations after termination defined.

9. Supplier Access Requirements

Document exactly what access the supplier requires.

Access TypeRequired?Approved?Owner
Email
VPN
SaaS Application
Cloud Console
Production Environment
Database
Source Code
Security Tools
Customer Data
Personal Data
Administrative Access

Access Controls

  • Access is based on documented business need.
  • Named individual accounts are used.
  • Shared accounts are avoided unless specifically justified.
  • MFA is enabled where required.
  • Least privilege has been applied.
  • Privileged access has additional approval.
  • Production access has been separately approved.
  • Temporary access has an expiry date where appropriate.
  • Access owner has been identified.
  • Access review frequency has been defined.

10. Information Sharing

Before sharing information with the supplier:

  • Information types identified.
  • Information classification confirmed.
  • Minimum necessary information determined.
  • Customer information requirements reviewed.
  • Personal data requirements reviewed.
  • Data transfer method approved.
  • Encryption requirements confirmed.
  • Retention requirements defined.
  • Data deletion/return requirements defined.
  • Supplier’s authorized recipients identified where appropriate.

Principle: Do not provide a supplier with more information or access than is required to perform the contracted service.


11. Technical Onboarding

Where the supplier requires technical integration:

  • Integration architecture reviewed.
  • Network connectivity approved.
  • API access reviewed.
  • Authentication method approved.
  • MFA configured where applicable.
  • Service accounts documented.
  • Secrets managed securely.
  • Encryption configured.
  • Logging enabled.
  • Monitoring configured where required.
  • Security alerts configured where appropriate.
  • Firewall/security-group rules reviewed.
  • Production connectivity approved.
  • Security testing completed where required.

12. Cloud Supplier Onboarding

For cloud or technology suppliers, consider:

  • Cloud/service architecture reviewed.
  • Data location identified.
  • Account ownership defined.
  • IAM requirements reviewed.
  • MFA enabled.
  • Privileged roles restricted.
  • Logging enabled.
  • Administrative activities monitored.
  • Encryption requirements confirmed.
  • Backup requirements confirmed.
  • Recovery requirements assessed.
  • Security monitoring integrated where required.
  • Subprocessors identified.
  • Exit/migration requirements considered.

AWS SaaS Example

If a SaaS startup onboards a critical AWS-related supplier:

Supplier → Service → AWS Environment → IAM Access → Data → Security Controls → Monitoring → Review

The supplier should receive only the permissions necessary for the contracted service. Administrative access should be separately approved, MFA-protected, monitored, and periodically reviewed.


13. Security Validation Before Go-Live

Before the supplier begins production activities:

  • Required security documentation received.
  • Required certifications/assurance evidence reviewed.
  • Security questionnaire reviewed.
  • Risk assessment completed.
  • Security findings addressed or accepted.
  • Required contractual controls completed.
  • Access approved.
  • MFA validated where applicable.
  • Technical controls validated where applicable.
  • Data-transfer mechanism validated.
  • Incident contacts confirmed.
  • Business continuity requirements reviewed.
  • Exit requirements considered.

14. Supplier Security Orientation

Where appropriate, provide the supplier with applicable security requirements.

  • Information security requirements communicated.
  • Acceptable use requirements communicated.
  • Confidentiality requirements communicated.
  • Data protection requirements communicated.
  • Incident reporting process communicated.
  • Security contact details provided.
  • Access requirements communicated.
  • Customer information handling requirements communicated.
  • Security escalation process communicated.

15. Supplier Contacts

RoleNameEmailPhoneConfirmed
Supplier Account Manager
Supplier Security Contact
Supplier Privacy Contact
Internal Business Owner
Internal Security Owner
Internal Procurement Owner

16. Business Continuity and Disaster Recovery

For medium, high, or critical suppliers:

  • Supplier BCP/DR capability reviewed.
  • Service availability requirements documented.
  • Recovery expectations documented.
  • RTO/RPO requirements considered where applicable.
  • Backup arrangements reviewed where relevant.
  • Critical dependency identified.
  • Alternative arrangement considered.
  • Exit/migration strategy considered.
  • Business continuity evidence retained where required.

17. Critical Supplier Requirements

For critical suppliers:

  • Supplier included in Critical Supplier Register.
  • Enhanced due diligence completed.
  • Enhanced security assessment completed.
  • Business dependency documented.
  • Production/privileged access assessed.
  • Security assurance reviewed.
  • BCP/DR capability assessed.
  • Concentration risk considered.
  • Alternative arrangements considered.
  • Exit/migration plan documented.
  • Enhanced monitoring frequency defined.
  • Management approval obtained where required.

18. Findings and Exceptions

Any onboarding issue should be documented.

Finding IDFindingRiskActionOwnerDue DateStatus

Examples:

  • Missing security certification
  • MFA not yet configured
  • Contract security clause pending
  • Subprocessor information incomplete
  • Data location unclear
  • Required security evidence unavailable
  • Production access requires additional controls

Where an issue cannot be resolved before onboarding, document the risk, compensating controls, owner, due date, and approval.


19. Final Onboarding Approval

Before go-live, confirm:

  • Business owner approval completed.
  • Procurement approval completed.
  • Legal approval completed where applicable.
  • Security approval completed where required.
  • Privacy approval completed where required.
  • Risk approval completed where required.
  • Contract executed.
  • Access approved.
  • Required security controls implemented.
  • Outstanding risks documented.
  • Exceptions formally accepted where applicable.
  • Supplier Register updated.
  • Critical Supplier Register updated where applicable.
  • Review date established.

Final Decision

Supplier Onboarding Status:

  • ☐ Approved
  • ☐ Approved with Conditions
  • ☐ Pending Remediation
  • ☐ Pending Management Risk Acceptance
  • ☐ Not Approved

Approval Comments:


Approved By: __________________

Role: __________________

Date: __________________


20. Go-Live Checklist

  • Supplier account/service activated.
  • Required access provisioned.
  • Access tested.
  • MFA verified.
  • Integration tested.
  • Logging/monitoring verified.
  • Data transfer tested where applicable.
  • Security controls validated.
  • Business owner confirms service readiness.
  • Security owner confirms security readiness.
  • Supplier officially marked as Active.

21. Post-Onboarding Review

For higher-risk suppliers, conduct an early post-onboarding review after an appropriate period.

Check:

  • Actual service matches approved scope.
  • Actual access matches approved access.
  • No unnecessary privileges identified.
  • Information handling matches expectations.
  • Security incidents reviewed.
  • Issues identified during initial operation documented.
  • Supplier risk remains appropriate.
  • Supplier records updated.
  • Corrective actions tracked.

22. Required Evidence

Typical onboarding evidence may include:

  • Business justification
  • Supplier Register entry
  • Due Diligence Checklist
  • Supplier Security Questionnaire
  • Supplier Risk Assessment
  • Security assessment
  • Certifications/assurance reports
  • NDA
  • Contract/MSA
  • SOW
  • DPA
  • Security Agreement
  • Access approval
  • IAM/access configuration evidence
  • MFA evidence
  • Data-flow/integration documentation
  • BCP/DR evidence
  • Subprocessor information
  • Risk acceptance
  • Onboarding approval
  • Go-live confirmation

Store evidence in the organization’s approved repository. Do not store passwords, API keys, private keys, or other secrets in the checklist.


23. Startup-Friendly Onboarding Model

A startup does not need to perform the same level of onboarding for every supplier.

Low-Risk Supplier

Examples:

  • Office supplies
  • Non-sensitive business services
  • Suppliers with no system or information access

Minimum:

Business Need → Basic Due Diligence → Contract → Approval → Register

Medium-Risk Supplier

Examples:

  • SaaS applications
  • HR systems
  • Marketing platforms
  • Business software

Add:

Security Questionnaire → Risk Assessment → Access Review → Privacy/Data Review → Security Contract Terms

High/Critical Supplier

Examples:

  • Cloud infrastructure
  • Payment providers
  • Identity providers
  • Customer-data processors
  • Critical production technology

Add:

Enhanced Due Diligence → Security Assessment → Technical Review → Privileged Access Controls → BCP/DR → Assurance Evidence → Enhanced Contractual Controls → Exit Planning → Enhanced Monitoring


24. Relationship With Other Supplier Documents

DocumentPrimary Purpose
Supplier RegisterMaintain the overall supplier inventory
Critical Supplier RegisterIdentify suppliers requiring enhanced oversight
Third-Party Due Diligence ChecklistEvaluate supplier before engagement
Supplier Risk AssessmentAnalyze supplier-related risks
Supplier Security QuestionnaireCollect security information from supplier
Supplier Onboarding ChecklistConfirm onboarding requirements are completed
Supplier Security AgreementDefine contractual security obligations
Supplier Security ReviewPeriodically reassess supplier security
Supplier Access ReviewReview supplier access rights
Supplier Offboarding ProcedureSecurely terminate supplier relationship
Risk RegisterTrack significant organizational risks

The Supplier Onboarding Checklist connects these activities into one controlled onboarding workflow.


25. ISO 27001 Connection

Supplier onboarding supports the organization’s broader information-security and risk-management processes, including supplier relationships, contractual security requirements, ICT supply-chain considerations, access control, information transfer, incident management, business continuity, and risk treatment.

The checklist itself is not a universally mandatory ISO 27001 document. The organization should determine the required onboarding activities based on its ISMS scope, risk assessment, applicable controls, legal and regulatory obligations, customer commitments, and Statement of Applicability.


26. Quick Audit Checklist

An auditor should be able to trace:

Business Need
↓
Supplier Identification
↓
Due Diligence
↓
Risk Assessment
↓
Security Requirements
↓
Contract
↓
Access Approval
↓
Security Validation
↓
Onboarding Approval
↓
Go-Live
↓
Supplier Monitoring & Review

If the organization can demonstrate this chain with appropriate evidence, supplier onboarding becomes an auditable process rather than simply a procurement activity.


27. Final Principle

Do not onboard a supplier simply because the business needs the service. Onboard the supplier only after understanding what the supplier will do, what information it will handle, what access it requires, what risks it introduces, what security requirements apply, who approved the relationship, and how the relationship will be monitored and exited.

Audit Trail:

Supplier → Business Need → Due Diligence → Risk → Security Requirements → Contract → Access → Validation → Approval → Go-Live → Monitoring → Review → Exit

How can we help?

Leave a Reply

Your email address will not be published. Required fields are marked *