1. Purpose
The Supply Chain Risk Assessment is used to identify, evaluate, and manage information-security, technology, operational, business, privacy, and continuity risks arising from the organization’s supply chain.
The assessment helps the organization understand:
- Which suppliers and third parties create significant risk
- What information, systems, technology, or business services depend on them
- What could happen if a supplier is compromised, unavailable, or unable to deliver
- Whether appropriate security controls are in place
- Whether supplier concentration or single points of failure exist
- Whether contractual and assurance requirements are adequate
- Whether risks require treatment, monitoring, or formal acceptance
The objective is to manage supply-chain risk based on actual dependency and business impact, rather than simply collecting supplier certifications.
2. Core Supply Chain Risk Principle
A practical assessment follows this chain:
Supplier → Service → Information → Technology → Access → Dependency → Threat → Vulnerability → Impact → Risk → Controls → Treatment → Residual Risk → Approval → Monitoring
For example:
Cloud supplier → Production hosting → Customer data → AWS infrastructure → Privileged administrative access → Critical dependency → Cloud outage or account compromise → Service disruption/data exposure → High risk → MFA, least privilege, logging, encryption, backup and recovery controls → Residual risk → Approval → Continuous monitoring
3. Scope
The assessment may cover:
- Cloud providers
- SaaS providers
- IaaS/PaaS providers
- Software suppliers
- Managed service providers
- IT support providers
- Security service providers
- Data processors
- Contractors
- Consultants
- Payment providers
- Backup providers
- Network providers
- Data-center providers
- Hardware suppliers
- Development partners
- Outsourced business processes
- Open-source software dependencies
- Software component suppliers
- Subprocessors
- Critical technology platforms
- Other external parties supporting important business services
The level of assessment should be proportionate to the supplier’s risk and criticality.
4. When Should a Supply Chain Risk Assessment Be Performed?
Perform the assessment:
- Before onboarding a high-risk or critical supplier
- Before granting significant system access
- Before sharing sensitive or customer information
- Before using a supplier for a critical business service
- During supplier renewal
- During periodic supplier review
- When the supplier changes its service
- When a new subprocessor is introduced
- When the supplier changes hosting/data location
- Following a significant security incident
- Following a major vulnerability
- When business dependency increases
- When a supplier becomes critical
- When a supplier is approaching end-of-life or discontinuation
- When concentration risk changes
5. Assessment Information
| Field | Details |
|---|---|
| Assessment ID | SCRA-001 |
| Supplier ID | |
| Supplier Name | |
| Supplier Type | |
| Service | |
| Business Owner | |
| Supplier Owner | |
| Assessment Date | |
| Assessment Trigger | New / Periodic / Change / Incident / Other |
| Assessment Scope | |
| Criticality | Low / Medium / High / Critical |
| Assessor | |
| Next Review Date | |
| Status | Open / Treatment / Accepted / Closed |
6. Supplier and Service Identification
Document exactly what the supplier provides.
| Field | Details |
|---|---|
| Supplier | |
| Service/Product | |
| Service Description | |
| Business Process Supported | |
| Application/System | |
| Technology | |
| Hosting Model | Cloud / SaaS / On-Premises / Hybrid |
| Supplier Location | |
| Service Location | |
| Data Location | |
| Contract Reference | |
| Service Owner | |
| Supplier Contact |
Avoid assessing a supplier only at company level.
For example:
“ABC Technologies” may provide both low-risk marketing services and critical production hosting. The risk assessment should distinguish between those services.
7. Business Dependency Assessment
Determine how important the supplier is to the organization.
| Question | Response |
|---|---|
| Does a critical business process depend on the supplier? | |
| Does customer service depend on the supplier? | |
| Does revenue depend on the supplier? | |
| Does production depend on the supplier? | |
| Does security monitoring depend on the supplier? | |
| Does identity/authentication depend on the supplier? | |
| Does regulatory compliance depend on the supplier? | |
| Would supplier failure stop an important business activity? | |
| Can the service be performed internally? | |
| Is an alternative supplier available? |
8. Information Assessment
Identify information shared with, stored by, or accessible to the supplier.
| Information | Applicable? |
|---|---|
| Public Information | |
| Internal Information | |
| Confidential Information | |
| Restricted Information | |
| Customer Information | |
| Personal Data | |
| Financial Information | |
| Authentication Information | |
| Source Code | |
| Security Information | |
| Business-sensitive Information | |
| Regulatory Information |
Record:
Classification:
Volume:
Data Subjects:
Retention Requirement:
Data Location:
Processing Purpose:
The organization should not automatically classify all supplier relationships as high risk. The actual information and processing activity should drive the assessment.
9. Access Assessment
Determine what access the supplier has.
| Access Type | Yes/No | Details |
|---|---|---|
| No System Access | ||
| Application Access | ||
| Internal Network Access | ||
| Cloud Access | ||
| Production Access | ||
| Database Access | ||
| Source Code Access | ||
| Administrative Access | ||
| Privileged Access | ||
| Remote Access | ||
| API Access | ||
| Customer Data Access | ||
| Personal Data Access |
Additional Questions
- Are individual accounts used?
- Is MFA enabled?
- Is least privilege applied?
- Is access time-limited?
- Is privileged access approved?
- Is supplier access logged?
- Are access reviews performed?
- Is access automatically removed at termination?
10. Supplier Criticality
Classify the supplier according to business and security impact.
| Level | Example Description |
|---|---|
| Low | Limited business impact and no sensitive information or significant system access. |
| Medium | Important service or information dependency, but alternatives exist. |
| High | Significant dependency, sensitive information, important access, or major business impact. |
| Critical | Failure or compromise could materially affect critical services, customers, security, regulatory obligations, or business continuity. |
These categories are examples and should be aligned with the organization’s approved risk methodology.
11. Supply Chain Threat Assessment
Consider relevant threats.
| Threat | Applicable? | Notes |
|---|---|---|
| Supplier cyberattack | ||
| Supplier account compromise | ||
| Insider threat | ||
| Data breach | ||
| Malware/ransomware | ||
| Software supply-chain compromise | ||
| Vulnerable third-party component | ||
| Unauthorized subcontractor | ||
| Subprocessor compromise | ||
| Supplier service outage | ||
| Supplier financial failure | ||
| Supplier discontinuation | ||
| Geopolitical disruption | ||
| Infrastructure failure | ||
| Data-center outage | ||
| Loss of key personnel | ||
| Regulatory change | ||
| Contract failure | ||
| Data-location issue | ||
| Technology end-of-life |
Only threats relevant to the supplier and service should be assessed.
12. Vulnerability Assessment
Identify weaknesses that could increase supply-chain risk.
Examples:
- Weak supplier security controls
- No MFA
- Excessive privileged access
- Unsupported software
- Inadequate vulnerability management
- No independent security assurance
- Weak incident notification
- No tested business continuity
- Excessive subcontractor dependency
- Unclear data location
- Poor access termination
- Lack of encryption
- Insufficient logging
- Weak change management
- No exit strategy
- Concentration on a single supplier
- Inability to recover data
- Poor software provenance
13. Supplier Security Control Assessment
Assess the supplier’s relevant controls.
| Control Area | Status | Evidence |
|---|---|---|
| Information Security Governance | ||
| Security Policies | ||
| Risk Management | ||
| Access Control | ||
| MFA | ||
| Privileged Access | ||
| Personnel Security | ||
| Security Awareness | ||
| Endpoint Security | ||
| Network Security | ||
| Cloud Security | ||
| Application Security | ||
| Vulnerability Management | ||
| Secure Development | ||
| Encryption | ||
| Logging & Monitoring | ||
| Incident Management | ||
| Breach Notification | ||
| Backup | ||
| Business Continuity | ||
| Disaster Recovery | ||
| Data Protection | ||
| Privacy | ||
| Subprocessor Management | ||
| Change Management | ||
| Physical Security | ||
| Security Testing | ||
| Independent Assurance |
Possible evidence includes:
- ISO 27001 certificate
- SOC 2 report
- Penetration-test summary
- Security questionnaire
- Security policies
- Business continuity evidence
- Disaster recovery test results
- Vulnerability-management evidence
- Incident-management process
- Data-processing documentation
A certification or assurance report is evidence, but it should not automatically eliminate the need for risk assessment.
14. Supplier Concentration Risk
Determine whether the organization is overly dependent on a supplier or technology ecosystem.
Consider:
- Number of critical services using the supplier
- Number of applications dependent on the supplier
- Number of business units dependent on the supplier
- Whether backup services use the same provider
- Whether disaster recovery uses the same provider
- Whether monitoring depends on the same provider
- Whether another supplier could replace the service
- Migration complexity
Concentration Assessment
| Field | Details |
|---|---|
| Supplier | |
| Critical Services Dependent | |
| Applications Dependent | |
| Alternative Supplier | |
| Migration Difficulty | |
| Estimated Migration Time | |
| Concentration Risk | Low / Medium / High |
| Treatment |
15. Subprocessor and Fourth-Party Risk
Where the supplier relies on other organizations, assess:
- Subprocessors
- Cloud providers
- Data centers
- Software vendors
- Infrastructure providers
- Managed security providers
- Payment processors
- Other critical dependencies
Record:
| Subprocessor | Service | Data/Access | Location | Criticality | Assurance |
|---|
The organization should understand significant downstream dependencies where they could affect its own risk.
16. Geographic and Data-Location Risk
Assess:
- Where information is stored
- Where information is processed
- Where supplier personnel access information
- Cross-border transfers
- Applicable legal/regulatory requirements
- Data residency commitments
- Government-access considerations where relevant
- Data deletion requirements
Record:
Primary Location:
Processing Locations:
Cross-Border Transfer: Yes / No
Applicable Requirements:
Risk:
Controls:
17. Supply Chain Availability Risk
Assess the consequences of supplier unavailability.
| Question | Response |
|---|---|
| What service becomes unavailable? | |
| Which business process is affected? | |
| Which customers are affected? | |
| Maximum acceptable downtime | |
| RTO | |
| RPO | |
| Supplier SLA | |
| Supplier DR capability | |
| Internal workaround | |
| Alternative supplier | |
| Recovery procedure |
18. Exit and Resilience Assessment
Determine whether the organization can exit or replace the supplier.
Assess:
- Data export
- Data portability
- Alternative providers
- Migration tooling
- Contract termination provisions
- Transition period
- Technical dependencies
- Proprietary formats
- Migration cost
- Staff capability
- Data deletion
- Credential revocation
- Service transition
Exit Assessment
Exit Possible: Yes / No / Partially
Estimated Transition Period:
Alternative Provider:
Major Constraints:
Exit Plan Required: Yes / No
19. Contractual Risk Assessment
Confirm that the supplier agreement addresses relevant requirements.
| Requirement | Status |
|---|---|
| Confidentiality | |
| Security obligations | |
| Data protection | |
| Access controls | |
| Incident notification | |
| Breach notification | |
| Vulnerability notification | |
| Subprocessor requirements | |
| Data location | |
| Audit/assurance rights | |
| Business continuity | |
| Availability/SLA | |
| Data return | |
| Data deletion | |
| Termination | |
| Security requirements after termination |
Contractual requirements should be proportionate to the supplier’s risk and service.
20. Inherent Risk Assessment
Assess the risk before considering additional treatment.
| Risk Factor | Rating |
|---|---|
| Business Criticality | |
| Information Sensitivity | |
| Access Level | |
| Customer Impact | |
| Regulatory Impact | |
| Availability Dependency | |
| Supplier Criticality | |
| Concentration Risk | |
| Subprocessor Risk | |
| Geographic Risk | |
| Technology Risk | |
| Recovery Difficulty |
Inherent Risk: Low / Medium / High / Critical
The organization’s approved risk methodology should define how these factors are combined.
21. Supply Chain Risk Register
Record significant risks.
| Risk ID | Supplier | Risk Scenario | Vulnerability | Impact | Likelihood | Risk |
|---|---|---|---|---|---|---|
| SCR-001 | ||||||
| SCR-002 |
Example
Supplier: Cloud provider
Risk Scenario: Cloud service outage
Vulnerability: Critical SaaS platform depends on a single cloud provider
Impact: Customer service unavailable
Likelihood: Medium
Impact: High
Risk: High
22. Risk Treatment
For each significant risk, determine:
Mitigate
Implement additional controls.
Avoid
Stop using the supplier or service where appropriate.
Transfer
Use contractual, insurance, or other risk-transfer mechanisms where appropriate.
Accept
Accept the residual risk through the organization’s formal risk-acceptance process.
Record:
| Field | Details |
|---|---|
| Risk ID | |
| Treatment Decision | |
| Action | |
| Control | |
| Owner | |
| Target Date | |
| Status | |
| Evidence | |
| Residual Risk | |
| Approval |
23. Residual Risk
After existing and planned controls are considered:
Inherent Risk:
Existing Controls:
Additional Treatment:
Residual Risk:
Risk Owner:
Risk Acceptance Required:
Approval Date:
Residual risk should be accepted only by an appropriately authorized risk owner under the organization’s established process.
24. AWS SaaS Example
Consider a SaaS startup that uses:
- AWS for production infrastructure
- GitHub for source code
- Auth0/another identity provider for authentication
- Stripe for payments
- Datadog for monitoring
- A third-party support platform for customer support
The organization should not treat these suppliers as having identical risk.
Example Assessment
Supplier: AWS
Service: Production cloud infrastructure
Information: Customer/application data
Access: Administrative cloud access
Business Criticality: Critical
Dependency: Customer-facing SaaS platform
Failure Scenario: Major cloud service disruption
Potential Impact:
- Customer service interruption
- Revenue impact
- SLA impact
- Business continuity impact
Controls:
- MFA
- Least privilege
- Multi-AZ architecture
- Encryption
- Backup
- Monitoring
- Logging
- Incident response
- Recovery testing
- Infrastructure-as-Code
Additional Treatment:
- Validate recovery procedures
- Maintain data portability
- Review concentration risk
- Periodically test restoration
25. Software Supply Chain Risk
For software development environments, assess:
- Open-source dependencies
- Commercial libraries
- Frameworks
- Container images
- Package repositories
- SDKs
- CI/CD tools
- Build systems
- Source-code repositories
- AI/ML components
- Infrastructure-as-Code modules
- Third-party APIs
The assessment should consider:
Component → Source → Version → Maintainer → Vulnerability → License → Application → Business Impact → Risk → Treatment
This should connect with the organization’s:
- Software Dependency Inventory
- SBOM
- Vulnerability Register
- Third-Party Software Assessment
- Secure Development Process
26. Critical Supplier Assessment
For critical suppliers, perform enhanced assessment covering:
- Business criticality
- Customer impact
- Information classification
- Production access
- Privileged access
- Security assurance
- Incident notification
- Business continuity
- Disaster recovery
- Subprocessors
- Concentration risk
- Geographic risk
- Contractual protections
- Recovery capability
- Exit/migration capability
- Residual risk
Critical suppliers should normally receive more frequent and detailed review than low-risk suppliers.
27. Monitoring Requirements
After onboarding, supply-chain risk should not be considered permanently closed.
Monitor relevant indicators such as:
- Security incidents
- Supplier breaches
- Major vulnerabilities
- Service outages
- SLA performance
- Certification status
- Assurance reports
- Material service changes
- New subprocessors
- Data-location changes
- Ownership changes
- Technology changes
- Contract changes
- Financial/operational concerns
- Regulatory changes
- End-of-life technologies
28. Reassessment Triggers
Reassess supply-chain risk when:
- Supplier service changes
- Supplier ownership changes
- New information is shared
- New system access is provided
- Privileged access is introduced
- Supplier adds a critical subprocessor
- Data location changes
- A major security incident occurs
- A critical vulnerability is identified
- Business dependency increases
- Supplier performance deteriorates
- Contract is renewed or materially amended
- Technology becomes obsolete
- A critical supplier becomes unavailable
- A new regulatory requirement applies
29. Evidence to Retain
Typical evidence includes:
- Completed risk assessment
- Supplier questionnaire
- Due-diligence checklist
- Supplier security assessment
- Security certifications
- SOC reports
- Penetration-test evidence
- Contracts
- Security addendum
- DPA
- Subprocessor list
- Data-location assessment
- Business continuity evidence
- Disaster recovery evidence
- Risk treatment records
- Risk acceptance
- Supplier review records
- Incident records
- Monitoring evidence
- Exit/migration plan
Never store passwords, API keys, private keys, or other secrets in the assessment.
30. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Supplier Register | Identifies suppliers |
| Critical Supplier Register | Identifies critical suppliers |
| Supplier Risk Assessment | Detailed risk assessment of a supplier |
| Supplier Due Diligence Checklist | Initial supplier evaluation |
| Supplier Security Questionnaire | Collects supplier security information |
| Supplier Security Assessment | Evaluates supplier controls |
| ICT Dependency Register | Identifies technology dependencies |
| Critical Technology Dependency Assessment | Evaluates critical technology dependencies |
| Software Dependency Inventory | Tracks software dependencies |
| SBOM | Tracks software components |
| Risk Register | Records significant supply-chain risks |
| Supplier Contract Review | Verifies contractual protections |
| Supplier Security Review | Performs periodic reassessment |
| Supplier Offboarding Checklist | Manages secure termination |
| Business Continuity Plan | Addresses continuity |
| Incident Management | Handles supply-chain incidents |
31. Roles and Responsibilities
Business Owner
- Defines business dependency
- Identifies business impact
- Confirms service criticality
Supplier Owner
- Manages supplier relationship
- Coordinates assessment
- Tracks supplier performance
Information Security
- Evaluates security risks
- Reviews security controls
- Supports risk treatment
Procurement
- Supports supplier due diligence
- Maintains commercial information
- Coordinates contractual requirements
Legal/Privacy
- Reviews contractual and privacy requirements
- Assesses applicable legal obligations
Risk Owner
- Owns the identified risk
- Approves treatment
- Accepts residual risk where authorized
32. Startup-Friendly Risk Model
A startup can use a simple three-tier approach.
Standard
For suppliers with:
- No sensitive information
- No production access
- Limited business impact
Use basic due diligence and contract review.
Important
For suppliers with:
- Internal/confidential information
- Important business processes
- Application access
- Moderate dependency
Perform detailed security and risk assessment.
Critical
For suppliers with:
- Customer data
- Production access
- Privileged access
- Critical business services
- Major availability dependency
- Significant regulatory impact
- Difficult replacement
Perform enhanced supply-chain risk assessment and periodic monitoring.
33. Common Mistakes
Mistake 1 — Treating every supplier equally
Risk should be proportionate to dependency and impact.
Mistake 2 — Only checking ISO certificates
A certificate does not by itself answer whether the supplier’s specific service, access, data, or dependency is appropriate.
Mistake 3 — Ignoring subcontractors
Important downstream dependencies can introduce additional risk.
Mistake 4 — Ignoring availability
Supply-chain risk is not limited to confidentiality and data breaches.
Mistake 5 — Ignoring exit
A supplier may be secure but still create unacceptable concentration or lock-in risk.
Mistake 6 — Never reassessing suppliers
Supplier risk changes over time.
Mistake 7 — Keeping the assessment disconnected from the risk register
Significant supply-chain risks should flow into the organization’s broader risk-management process.
34. Quick Audit Checklist
| Question | Yes/No/N/A |
|---|---|
| Are important suppliers identified? | |
| Is the service provided by each supplier documented? | |
| Is business dependency understood? | |
| Is information shared with the supplier identified? | |
| Is supplier access documented? | |
| Is supplier criticality determined? | |
| Are relevant threats identified? | |
| Are supplier vulnerabilities considered? | |
| Are security controls evaluated? | |
| Are subcontractors/subprocessors considered? | |
| Is concentration risk assessed? | |
| Is availability dependency assessed? | |
| Are recovery arrangements reviewed? | |
| Is exit/migration capability considered? | |
| Are contractual requirements reviewed? | |
| Are significant risks recorded? | |
| Are treatment actions assigned? | |
| Is residual risk evaluated? | |
| Is risk acceptance formally approved where required? | |
| Is supplier risk periodically monitored? | |
| Are reassessment triggers defined? | |
| Is evidence retained? |
35. Final Supply Chain Risk Assessment Record
A completed assessment should provide a clear picture:
Supplier Identified
↓
Service Identified
↓
Business Dependency Understood
↓
Information & Access Assessed
↓
Technology Dependency Identified
↓
Threats & Vulnerabilities Assessed
↓
Supplier Controls Evaluated
↓
Concentration & Subprocessor Risk Assessed
↓
Availability & Recovery Assessed
↓
Exit/Migration Assessed
↓
Inherent Risk Determined
↓
Treatment Defined
↓
Residual Risk Determined
↓
Risk Approved
↓
Supplier Monitored
↓
Risk Reassessed
Final Principle
A supply-chain risk assessment should answer five practical questions:
- What do we depend on?
- What information, systems, or business services are exposed to that dependency?
- What could go wrong?
- What controls and recovery arrangements reduce the risk?
- What happens if we can no longer use the supplier?
The result should be a risk-based view of the organization’s supply chain, connected directly to supplier management, technology dependencies, risk treatment, business continuity, security controls, and the ISMS.