ICT Supply Chain Security Policy

1. Purpose

The purpose of this ICT Supply Chain Security Policy is to establish requirements for identifying, assessing, managing, monitoring, and controlling information-security risks arising from the organization’s ICT supply chain.

The policy ensures that suppliers, technology providers, cloud providers, software vendors, managed service providers, contractors, and other ICT-related third parties are appropriately evaluated and managed throughout their relationship with the organization.

The objective is to protect:

Confidentiality of information
Integrity of information and systems
Availability of critical services
Customer and personal data
Credentials, keys, and secrets
Source code and intellectual property
Production and cloud environments
Business continuity and service delivery

2. Scope

This policy applies to ICT products, services, technologies, and suppliers that may affect the organization’s information security.

It covers, as applicable:

Cloud service providers
SaaS providers
IaaS/PaaS providers
Software vendors
Hardware suppliers
Managed service providers
IT support providers
Security service providers
VAPT providers
Backup providers
Data-center providers
Internet/network providers
Identity and authentication providers
Payment technology providers
Development and technology partners
Open-source and third-party software components
Subcontractors and subprocessors
Contractors with access to ICT systems or information

The scope should be applied based on supplier criticality, information handled, access provided, service dependency, and associated risks.

3. Policy Statement

The organization shall manage ICT supply-chain security using a risk-based approach.

ICT suppliers shall be:

Identified
Classified according to their importance and risk
Subjected to appropriate due diligence
Assessed for information-security risks
Provided with applicable security requirements
Contractually bound to relevant security obligations
Granted only necessary access
Monitored during the relationship
Periodically reassessed
Securely offboarded when the relationship ends

Security requirements shall be proportionate to the nature and risk of the supplier relationship.

4. ICT Supply Chain Security Principles

The organization shall follow these principles:

4.1 Risk-Based Management

Supplier security requirements shall be determined based on:

Information handled
Data sensitivity
System access
Privileged access
Production access
Customer impact
Business criticality
Service dependency
Regulatory requirements
Contractual obligations
Supplier/subprocessor dependency
Availability requirements

4.2 Least Privilege

Suppliers shall receive only the access required to perform their approved services.

4.3 Security by Contract

Relevant security requirements shall be incorporated into contracts, agreements, SOWs, DPAs, security addenda, or other applicable contractual arrangements.

4.4 Evidence-Based Assurance

Where appropriate, suppliers shall provide evidence such as:

ISO 27001 certification
SOC 2 reports
Security assessment reports
Penetration-testing reports
Business continuity evidence
Security policies
Data protection documentation
Independent assurance reports

A certification or report shall not automatically eliminate the organization’s responsibility to assess the supplier’s specific risks.

4.5 Continuous Oversight

Supplier security shall not be considered complete after onboarding. Appropriate monitoring and reassessment shall continue throughout the supplier lifecycle.

5. ICT Supply Chain Lifecycle

The organization shall manage ICT suppliers through the following lifecycle:

Business Need → Supplier Identification → Classification → Due Diligence → Risk Assessment → Security Requirements → Contract → Onboarding → Access → Monitoring → Review → Reassessment → Offboarding

Records should be maintained to demonstrate the lifecycle where applicable.

6. Supplier Identification and Classification

The organization shall maintain an appropriate supplier inventory or register.

Each relevant ICT supplier should be classified according to factors such as:

Factor	Example
Service	Cloud hosting
Information	Customer data
Access	Production access
Criticality	Business critical
Dependency	High
Data	Personal/confidential
Privileged Access	Yes/No
Subprocessors	Yes/No
Regulatory Impact	Applicable/Not applicable
Risk	Low/Medium/High/Critical

Supplier criticality shall be documented where it materially affects security or business continuity.

7. Supplier Due Diligence

Before onboarding a relevant ICT supplier, the organization shall perform appropriate due diligence.

Depending on risk, due diligence may include:

Supplier identity and legitimacy
Ownership and organizational information
Service description
Security governance
Security certifications
Security policies
Access controls
MFA
Encryption
Vulnerability management
Incident management
Backup and recovery
Business continuity
Privacy controls
Subprocessors
Data location
Security testing
Regulatory requirements
Contractual security obligations

The depth of due diligence shall be proportionate to the supplier’s risk.

8. ICT Supply Chain Risk Assessment

Relevant suppliers shall undergo an information-security risk assessment.

The assessment should consider:

Supplier → Service → Information → Access → Dependency → Threat → Vulnerability → Impact → Risk → Controls → Treatment → Residual Risk

Risk assessments shall identify appropriate treatment actions where risks exceed the organization’s defined acceptance criteria.

9. Security Requirements for Suppliers

The organization shall establish applicable security requirements for ICT suppliers.

Requirements may include:

Access Control

Unique user accounts
Least privilege
MFA
Access approval
Periodic access review
Privileged-access management
Timely access removal

Information Protection

Information classification
Confidentiality
Secure information handling
Data minimization
Secure information transfer
Secure disposal

Technical Security

Vulnerability management
Malware protection
Secure configuration
Encryption
Logging and monitoring
Secure development
Security testing

Incident Management

Suppliers shall have appropriate processes for:

Detecting security incidents
Reporting incidents
Investigating incidents
Containing incidents
Supporting investigations
Providing relevant information to the organization

Business Continuity

Critical suppliers should maintain appropriate:

Backup arrangements
Recovery capabilities
Business continuity arrangements
Disaster recovery arrangements
Service availability controls

10. ICT Supply Chain Contractual Requirements

Security requirements shall be incorporated into supplier contracts where applicable.

Contracts should address, as appropriate:

Confidentiality
Information security
Data protection
Access control
MFA
Privileged access
Security incident notification
Data breach notification
Vulnerability management
Security testing
Subprocessors
Data location
Data transfers
Backup and recovery
Business continuity
Security assurance
Audit/assessment rights
Security changes
Data retention
Data return and deletion
Supplier termination
Security obligations after termination

Contractual requirements should reflect the actual risks associated with the supplier.

11. Cloud and SaaS Supply Chain Security

Cloud and SaaS suppliers shall be assessed according to the organization’s risk methodology.

Assessment may include:

Cloud architecture
Data storage
Data location
Encryption
Identity and access management
MFA
Logging
Security monitoring
Backup
Disaster recovery
Availability
Subprocessors
Security certifications
Security incidents
Vulnerability management
Exit and migration arrangements

Example — AWS SaaS Startup

A startup hosting its production application on AWS may classify AWS as a critical ICT supplier.

The organization should understand:

Which production systems depend on AWS
What customer information is stored
IAM and privileged access arrangements
MFA requirements
Logging through services such as CloudTrail
Monitoring arrangements
Encryption and key management
Backup and recovery
Availability requirements
Business continuity arrangements
Supplier assurance information
Exit or migration considerations

The objective is not simply to record “AWS = Critical,” but to demonstrate why the dependency is critical and how associated risks are controlled.

12. Third-Party Software and Technology Components

The organization shall consider security risks associated with third-party software and technology components.

Where applicable, the organization shall maintain appropriate controls for:

Software provenance
Approved software sources
Open-source components
Dependency management
Vulnerability monitoring
Software updates
Security patches
Software integrity
Version management
Secure development practices

Critical vulnerabilities affecting third-party components shall be evaluated and addressed according to the organization’s vulnerability-management process.

13. Subcontractors and Subprocessors

Where suppliers use subcontractors or subprocessors that may affect the organization’s information security, the organization shall assess the associated risks.

Depending on contractual and risk requirements, suppliers may be required to:

Disclose relevant subprocessors
Obtain approval before introducing material subprocessors
Flow down security requirements
Maintain appropriate oversight
Notify the organization of material changes
Provide relevant assurance information

14. Supplier Access Management

Supplier access shall be controlled throughout the supplier lifecycle.

The organization shall ensure, as applicable:

Access is business justified
Access is approved
Individual accounts are used
MFA is enabled
Least privilege is applied
Privileged access is restricted
Production access is controlled
Temporary access has an appropriate expiry
Access is monitored
Access is periodically reviewed
Access is removed when no longer required

Shared supplier accounts should be avoided unless there is a documented business and security justification.

15. Monitoring and Security Review

Relevant ICT suppliers shall be monitored based on their risk and criticality.

Monitoring may include:

Security incidents
Service outages
Vulnerabilities
SLA performance
Security-control changes
Certification status
Audit reports
Security-test results
Subprocessor changes
Data-location changes
Ownership changes
Significant service changes
Security breaches
Contract compliance

High-risk and critical suppliers should receive enhanced monitoring where appropriate.

16. Supplier Security Review

Supplier security shall be periodically reviewed according to risk.

The review may verify:

Current service scope
Current information processed
Current access
Security controls
Incidents
Vulnerabilities
Assurance reports
Subprocessors
Data locations
Business continuity
Contractual requirements
Open findings
Risk changes

The review frequency should be based on supplier risk and organizational requirements rather than applying the same frequency to every supplier.

17. Security Incident and Breach Management

Suppliers shall be required, where appropriate, to notify the organization of security incidents that may affect:

Organizational information
Customer information
Personal data
Production systems
Service availability
Confidentiality
Integrity
Regulatory or contractual obligations

The organization shall define applicable notification channels and escalation requirements.

Supplier incidents shall be incorporated into the organization’s incident-management process where relevant.

18. Supplier Business Continuity

For critical ICT suppliers, the organization shall consider the potential impact of supplier failure or service disruption.

Where appropriate, the organization shall assess:

Recovery capabilities
Backup arrangements
Recovery objectives
Service availability
Disaster recovery
Alternative suppliers
Migration capability
Exit strategy
Concentration risk

The level of assessment should reflect the organization’s dependency on the supplier.

19. Security Changes in the ICT Supply Chain

Suppliers shall be monitored for material changes that may affect information security.

Examples include:

New technology
New service architecture
New subprocessors
New data location
Change in ownership
Major service changes
Changes to security controls
Significant vulnerabilities
Security incidents
Changes in regulatory obligations

Material changes shall trigger reassessment where appropriate.

20. Supplier Offboarding

When an ICT supplier relationship ends, the organization shall ensure appropriate security closure.

This may include:

Access revocation
Privileged-access removal
Credential/token revocation
Data return
Data deletion
Asset recovery
System integration removal
API key removal
Secret rotation where necessary
Subprocessor considerations
Contract closure
Risk reassessment
Supplier register update

Evidence of completion shall be retained according to applicable record-retention requirements.

21. Exceptions

Any exception to this policy shall:

Be documented
Identify the affected requirement
Explain the business justification
Assess the associated risk
Define compensating controls where appropriate
Identify an owner
Define an expiry/review date
Receive appropriate approval

Exceptions shall not be treated as permanent alternatives to security controls.

22. Roles and Responsibilities

Role	Responsibility
Management	Approves policy and significant supplier risks
Information Security	Defines security requirements and performs/oversees security assessment
Supplier/Procurement Owner	Manages supplier relationship
Business Owner	Defines business need and service criticality
IT/Engineering	Reviews technical and access requirements
Privacy	Reviews personal-data and privacy requirements where applicable
Legal	Reviews contractual and legal requirements
Risk Owner	Accepts residual risk where required
Supplier	Meets agreed security requirements and provides appropriate evidence

23. Required Records and Evidence

Depending on the supplier and risk, records may include:

Supplier Register
Critical Supplier Register
Due Diligence Checklist
Supplier Questionnaire
Supplier Risk Assessment
Security Assessment
Security Requirements
Security Addendum
Contract Security Review
Data Processing Agreement
Security Assurance Reports
Supplier Security Review
Access Review
Incident Records
Corrective Action Records
Risk Acceptance
Offboarding Checklist
Data Deletion/Return Evidence

24. Risk-Based Supplier Model

A startup may use a simple model such as:

Risk Level	Typical Characteristics	Management Approach
Low	Limited information/access and low dependency	Basic due diligence and contractual controls
Medium	Confidential information or meaningful service dependency	Enhanced due diligence, security review and monitoring
High	Sensitive data, significant access or important business dependency	Detailed security assessment and enhanced contractual controls
Critical	Production/privileged access, critical infrastructure or major service dependency	Enhanced assessment, assurance, monitoring, continuity and exit planning

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

25. AWS SaaS Startup Example

Consider a SaaS startup providing services to enterprise customers.

The startup uses:

AWS for production infrastructure
GitHub for source code
Okta/Entra ID for identity
A third-party customer-support platform
Stripe for payments
A managed security provider

The organization should not manage all suppliers identically.

For example:

AWS

Production infrastructure
Customer data
High availability dependency
Security and continuity considerations

→ Enhanced supplier assessment and monitoring may be appropriate.

Customer-support SaaS

Customer information
Support tickets
Potential personal data

→ Privacy, access, encryption, subprocessors, incident, and deletion requirements should be considered.

Office stationery supplier

No system access
No sensitive information
Minimal ICT dependency

→ Extensive ICT security assessment would generally not be proportionate.

This demonstrates the principle:

Supplier security controls should follow actual risk, not simply the supplier’s name or category.

26. Relationship With Other ISMS Documents

This policy should operate together with the organization’s supplier-management documentation.

Document	Purpose
Supplier Register	Identifies suppliers
Critical Supplier Register	Identifies critical suppliers
Due Diligence Checklist	Performs initial supplier checks
Supplier Questionnaire	Collects supplier security information
Supplier Risk Assessment	Evaluates supplier risk
Supplier Security Requirements	Defines required controls
Supplier Security Addendum	Establishes contractual security requirements
Contract Security Review	Reviews security clauses
Supplier Security Review	Performs periodic reassessment
Supplier Access Review	Reviews supplier access
Supplier Offboarding Checklist	Secures supplier termination
Risk Register	Tracks significant organizational risks

The ICT Supply Chain Security Policy provides the overall governance framework connecting these activities.

27. ISO/IEC 27001 Connection

This policy supports the organization’s ISO/IEC 27001 ISMS by establishing a structured approach for managing security risks associated with ICT suppliers and supply-chain relationships.

Relevant areas include:

Supplier relationship security
ICT supply-chain security
Security requirements in supplier agreements
Access control
Information transfer
Incident management
Business continuity
Monitoring and review
Risk assessment and treatment
Secure termination of supplier relationships

The organization should determine applicable controls through its own risk assessment and Statement of Applicability rather than treating Annex A as a checklist.

28. Quick Audit Checklist

An auditor may ask:

Do you maintain a supplier register?
Have ICT suppliers been identified?
How do you determine supplier criticality?
How is supplier risk assessed?
Do suppliers receive appropriate security requirements?
Are security requirements included in contracts?
How do you manage supplier access?
Is MFA required where appropriate?
How are privileged supplier accounts controlled?
How are critical suppliers monitored?
How often are suppliers reassessed?
How are supplier incidents handled?
How are subprocessors managed?
How do you assess cloud suppliers?
How do you manage third-party software dependencies?
How do you address supplier business continuity?
How are supplier changes monitored?
How do you securely terminate supplier relationships?
Can you provide evidence for a critical supplier from onboarding through offboarding?

29. Final Audit Trail

A strong ICT supply-chain security program should produce an evidence chain such as:

Supplier Identified
↓
Supplier Classified
↓
Due Diligence Completed
↓
Security Risk Assessed
↓
Security Requirements Defined
↓
Contract Approved
↓
Supplier Onboarded
↓
Access Granted
↓
Security Monitored
↓
Periodic Review Completed
↓
Risk Reassessed
↓
Corrective Actions Managed
↓
Supplier Offboarded Securely

Final Principle

ICT supply-chain security is not simply about checking whether a supplier has ISO 27001 or SOC 2.

It is about demonstrating that the organization understands:

who its ICT suppliers are → what they provide → what information and systems they can affect → what risks they introduce → what security requirements apply → how those requirements are monitored → and how the relationship can be securely managed or terminated.

That evidence-based lifecycle is what makes the ICT supply chain manageable, auditable, and aligned with the organization’s information-security risk management process.

ISO/IEC 27001