1. Purpose
The Critical Supplier Review Template is used to perform a structured review of suppliers whose failure, compromise, unavailability, or poor security performance could significantly affect:
- Critical business operations
- Customer services
- Customer information
- Personal data
- Production systems
- Information security
- Regulatory or contractual obligations
- Business continuity
- Revenue or service delivery
The review provides a formal mechanism to determine whether the critical supplier:
- Continues to meet agreed security requirements
- Continues to provide the required service
- Maintains appropriate security controls
- Protects organizational and customer information
- Maintains appropriate access controls
- Remains operationally resilient
- Has acceptable security and privacy risk
- Has suitable recovery and exit arrangements
- Has experienced material changes
- Requires additional corrective action or risk treatment
2. Core Review Principle
The review should follow:
Critical Supplier → Critical Service → Information → Access → Dependency → Security → Availability → Changes → Risk → Evidence → Corrective Action → Approval → Monitoring
The key question is not:
“Does the supplier still have a certification?”
The key question is:
“Can we demonstrate that this critical supplier remains secure, reliable, resilient, contractually controlled, and appropriate for the risk we currently depend on it to manage?”
3. When to Perform the Review
A critical supplier review should be performed according to the organization’s defined monitoring and review process.
A review may be triggered by:
- Scheduled periodic review
- Major security incident
- Data breach
- Critical vulnerability
- Major supplier change
- New subprocessor
- Change in data location
- Change in ownership
- Acquisition or merger
- Significant service degradation
- New production access
- Increased dependency
- New sensitive information
- Assurance/certification expiry
- Regulatory change
- Contract renewal
- Major SLA failure
- Business continuity event
- Material change in supplier risk
The frequency should be risk-based rather than automatically identical for every critical supplier.
4. Critical Supplier Review Record
| Field | Details |
|---|---|
| Review ID | Unique review identifier |
| Supplier ID | Supplier identifier |
| Supplier Name | Legal/business name |
| Supplier Type | Cloud / SaaS / MSP / Processor / etc. |
| Critical Service | Business-critical service |
| Business Owner | Internal business owner |
| Supplier Owner | Relationship owner |
| Security Owner | Security reviewer |
| Review Type | Periodic / Event-driven |
| Review Date | Date |
| Review Period | Period covered |
| Previous Review | Reference |
| Current Status | Open / Complete |
| Overall Risk | Current risk rating |
| Review Decision | Continue / Conditions / Escalate / Exit Review |
5. Critical Supplier Profile
Document:
- Supplier name
- Legal entity
- Service
- Contract
- Contract start/end date
- Business owner
- Supplier relationship owner
- Security contact
- Privacy contact
- Criticality classification
- Critical business process
- Information handled
- Production access
- Privileged access
- Personal data
- Customer data
- Key subprocessors
- Data locations
- Business dependency
- Alternative supplier availability
6. Criticality Confirmation
Confirm why the supplier remains classified as critical.
Consider:
- Critical business service dependency
- Customer impact
- Production dependency
- Sensitive information
- Personal data
- Regulatory requirements
- Revenue impact
- Availability dependency
- Recovery dependency
- Security dependency
- Lack of practical alternatives
- Concentration risk
Document:
Why would failure of this supplier materially affect the organization?
7. Service Performance Review
Review whether the supplier continues to meet agreed service requirements.
Assess:
- Service availability
- SLA performance
- Support performance
- Response time
- Resolution time
- Service interruptions
- Recurring problems
- Customer-impacting incidents
- Planned maintenance
- Service degradation
- Contractual performance
| Metric | Requirement | Actual | Result |
|---|---|---|---|
| Availability | |||
| Incident response | |||
| Support response | |||
| Resolution | |||
| SLA compliance |
8. Information Security Review
Assess whether the supplier continues to maintain appropriate security controls covering:
Governance
- Security policies
- Security governance
- Risk management
- Security responsibilities
- Security awareness
Technical Controls
- Network security
- Endpoint security
- Vulnerability management
- Secure configuration
- Malware protection
- Security monitoring
Data Protection
- Encryption
- Key management
- Data retention
- Secure deletion
Application Security
Where applicable:
- Secure development
- Code review
- Security testing
- Dependency management
- Change management
9. Security Assurance Review
Review current assurance evidence.
Possible evidence:
- ISO/IEC 27001 certificate
- SOC 2 report
- Independent security assessment
- Penetration-test summary
- Vulnerability assessment
- Security questionnaire
- BCP/DR test report
- Privacy assessment
- Regulatory assessment
For each item confirm:
- Current
- Relevant
- Correct supplier/entity
- Appropriate scope
- Appropriate service
- No unacceptable exceptions
- Findings reviewed
- Expiry tracked
A certification should be treated as one source of assurance rather than the sole basis for the supplier’s risk assessment.
10. Security Evidence Review
Use the Supplier Security Evidence Review Checklist to evaluate evidence.
For each significant requirement determine:
| Requirement | Evidence | Scope | Result | Finding |
|---|---|---|---|---|
| MFA | ||||
| Privileged access | ||||
| Encryption | ||||
| Vulnerability management | ||||
| Logging | ||||
| Incident response | ||||
| Backup | ||||
| DR |
Document evidence gaps and follow-up actions.
11. Access Review
Review supplier access to organizational systems.
Assess:
- User accounts
- Individual accounts
- Shared accounts
- MFA
- Privileged accounts
- Production access
- Database access
- Cloud access
- Remote access
- API access
- Service accounts
- Temporary access
- Former supplier personnel
Confirm:
- Access remains necessary
- Access is approved
- Least privilege is applied
- MFA is enabled where required
- Privileged access is controlled
- Access is monitored
- Inactive access is removed
12. Privileged Access Review
For critical suppliers, separately review privileged access.
Record:
| Area | Review |
|---|---|
| Number of privileged users | |
| Business justification | |
| MFA | |
| Named accounts | |
| Role-based access | |
| Production access | |
| Temporary access | |
| Logging | |
| Periodic review | |
| Former personnel removed |
Where appropriate, verify privileged activity through available audit logs.
13. Customer Data Review
Determine whether the supplier’s handling of customer information has changed.
Review:
- Types of customer data
- Volume
- New data categories
- New processing purposes
- Data retention
- Access
- Data locations
- Encryption
- Customer commitments
- Deletion requirements
Document any material changes.
14. Personal Data and Privacy Review
Where personal data is involved, review:
- DPA
- Processing activities
- Data categories
- Data-subject categories
- Data locations
- International transfers
- Subprocessors
- Retention
- Deletion
- Privacy incidents
- Data-subject rights support
- Privacy/security controls
Determine whether the existing privacy arrangement remains appropriate.
15. Subprocessor Review
Review current subprocessors.
Confirm:
- Current list
- New subprocessors
- Removed subprocessors
- Services provided
- Data processed
- Locations
- Security assurance
- Further subprocessors
- Material changes
Determine whether a new subprocessor changes the supplier’s risk profile.
16. Data Location Review
Confirm current:
- Processing locations
- Storage locations
- Backup locations
- Disaster-recovery locations
- Support locations
- Administrative-access locations
Compare current locations with:
- Contract
- DPA
- Customer commitments
- Data-residency requirements
- Regulatory requirements
17. Security Incident Review
Review incidents during the assessment period.
Record:
| Incident | Date | Impact | Supplier Response | Corrective Action | Status |
|---|---|---|---|---|---|
Assess:
- Was the organization notified appropriately?
- Was customer data affected?
- Was production affected?
- Was root cause identified?
- Were corrective actions completed?
- Has supplier risk changed?
A supplier incident should trigger reassessment where appropriate.
18. Vulnerability Review
Review:
- Critical vulnerabilities
- High-risk vulnerabilities
- Major security findings
- Exploitation
- Remediation performance
- Recurring vulnerabilities
- Unsupported technologies
- Security-testing results
Determine whether unresolved vulnerabilities affect the organization’s risk.
19. Business Continuity Review
Review the supplier’s ability to continue critical service delivery.
Assess:
- Business continuity plan
- Disaster recovery plan
- Backup
- Redundancy
- Recovery testing
- RTO
- RPO
- Recovery locations
- Dependency on other suppliers
- Recovery communications
20. Recovery Test Review
Where relevant, obtain evidence of recent recovery testing.
Review:
- Test date
- Scenario
- Scope
- Systems affected
- Recovery achieved
- RTO achieved
- RPO achieved
- Issues identified
- Corrective actions
- Retest status
For critical services, determine whether recovery capability remains aligned with organizational requirements.
21. Dependency Review
Document the organization’s dependency on the supplier.
Consider:
- Number of business services affected
- Number of applications affected
- Number of customers affected
- Production dependency
- Data dependency
- Identity dependency
- Payment dependency
- Security dependency
- Infrastructure dependency
Example:
Customer SaaS → AWS → Production Infrastructure → Customer Service
22. Concentration Risk Review
Determine whether the organization has excessive dependence on:
- One cloud provider
- One identity provider
- One payment provider
- One network provider
- One backup provider
- One security provider
- One geographic region
- One supplier group
Ask:
What happens if this supplier becomes unavailable?
Also consider whether multiple suppliers depend on the same underlying provider.
23. Alternative Supplier Assessment
Determine whether an alternative exists.
Record:
- Alternative provider
- Service compatibility
- Migration complexity
- Estimated migration time
- Cost
- Data portability
- Technical dependency
- Contractual constraints
- Customer impact
An alternative may not need to be immediately implemented, but critical dependencies should be understood.
24. Exit and Migration Review
For critical suppliers, evaluate:
- Exit strategy
- Data export
- Data portability
- Data deletion
- Migration capability
- Contract termination
- Transition assistance
- Knowledge transfer
- Credential revocation
- Infrastructure migration
- Customer communication
- Backup availability
Document whether the organization could realistically exit the supplier if necessary.
25. Supplier Change Review
Review material changes since the previous assessment.
Examples:
- New ownership
- Acquisition
- New service
- Architecture change
- Cloud migration
- New subprocessor
- New country
- Data-location change
- Security-control change
- Authentication change
- Production-access change
- SLA change
- Contract change
- Product retirement
Each material change should be assessed through the organization’s supplier change-management process.
26. Contract Review
Confirm that the contract remains appropriate.
Review:
- Security obligations
- Confidentiality
- Privacy
- DPA
- Incident notification
- Subprocessors
- Audit/assurance rights
- Data return
- Data deletion
- Business continuity
- Availability
- SLA
- Security changes
- Termination
- Post-termination obligations
Identify expired or missing contractual requirements.
27. Corrective Action Review
Review all open supplier corrective actions.
| Action ID | Finding | Risk | Due Date | Status | Evidence |
|---|---|---|---|---|---|
Pay particular attention to:
- High-risk findings
- Overdue actions
- Recurring findings
- Security incidents
- Contractual violations
- Unresolved vulnerabilities
Use the Supplier Corrective Action Register for detailed tracking.
28. Supplier Security Performance
Assess overall supplier performance across relevant areas.
| Area | Result | Observation |
|---|---|---|
| Security controls | ||
| Access management | ||
| Vulnerability management | ||
| Incident management | ||
| Privacy | ||
| Availability | ||
| BCP/DR | ||
| Subprocessors | ||
| Assurance | ||
| Contract compliance | ||
| Corrective actions |
This is a structured assessment, not an overall ranking of suppliers.
29. Risk Reassessment
Reassess the supplier’s current risk.
Consider:
Service → Information → Access → Dependency → Threat → Vulnerability → Impact → Likelihood → Controls → Residual Risk
Compare:
- Previous risk
- Current inherent risk
- Current controls
- Current residual risk
- New risks
- Closed risks
Document whether risk:
- Increased
- Decreased
- Remained stable
- Requires further assessment
30. Risk Treatment
Where risk is not acceptable under the organization’s methodology, define treatment.
Possible actions:
- Additional security controls
- Access restriction
- Additional monitoring
- Contract amendment
- Additional assurance
- Security testing
- Backup/recovery improvement
- Alternative provider
- Exit planning
- Subprocessor restriction
- Data-location restriction
- Corrective action
- Risk acceptance
31. Critical Supplier Review Summary
Prepare an executive summary.
Supplier
[Supplier Name]
Critical Service
[Service]
Review Period
[Period]
Key Changes
[Summary]
Security Status
[Summary]
Major Findings
[Summary]
Open Corrective Actions
[Summary]
Business Continuity Status
[Summary]
Privacy Status
[Summary]
Current Risk
[Risk Rating]
Key Risks
[List]
Required Actions
[List]
Review Decision
[Decision]
32. Review Decision
Possible outcomes:
Continue
Supplier remains appropriate with current controls.
Continue With Conditions
Supplier may continue subject to defined corrective actions or controls.
Enhanced Monitoring
Supplier remains critical and requires increased monitoring.
Further Assessment Required
Additional information or testing is required before final determination.
Management Risk Acceptance
Remaining risk requires formal risk acceptance.
Exit / Replacement Assessment
Supplier risk or business circumstances require evaluation of alternative arrangements.
The decision should be based on the organization’s approved risk and supplier-management methodology.
33. Management Approval
For significant critical-supplier decisions, document:
| Field | Details |
|---|---|
| Review Outcome | |
| Current Risk | |
| Key Findings | |
| Required Actions | |
| Risk Owner | |
| Security Approval | |
| Business Approval | |
| Management Approval | |
| Approval Date | |
| Next Review |
34. Evidence Register
Maintain evidence supporting the review.
| Evidence ID | Evidence | Source | Date | Scope | Review Result |
|---|---|---|---|---|---|
| E-001 | ISO 27001 Certificate | Supplier | |||
| E-002 | SOC 2 Report | Supplier | |||
| E-003 | Pen Test Summary | Supplier | |||
| E-004 | DR Test Report | Supplier | |||
| E-005 | Subprocessor List | Supplier | |||
| E-006 | Access Review | Internal/Supplier | |||
| E-007 | SLA Report | Supplier |
Do not retain unnecessary credentials, secrets, private keys, or other sensitive technical information as review evidence.
35. AWS SaaS Example
Consider an organization whose customer-facing SaaS platform is hosted on AWS.
AWS is classified as a critical supplier because production applications and customer information depend on AWS infrastructure.
The critical supplier review may cover:
Service
- EC2/ECS
- RDS
- S3
- IAM
- CloudWatch
- CloudTrail
- KMS
- WAF
Security
- MFA
- IAM least privilege
- Privileged access
- Encryption
- Logging
- Monitoring
- Vulnerability management
Availability
- Multi-AZ architecture
- Backups
- Recovery testing
- RTO/RPO
Dependency
- Production applications
- Customer data
- Authentication
- Storage
- Database
- Security monitoring
Resilience
- Backup strategy
- Data portability
- Migration capability
- Alternative architecture
- Exit considerations
The review should focus on the organization’s actual dependency and architecture, rather than simply recording that AWS has security certifications.
36. Startup-Friendly Critical Supplier Review
For a startup, the review can be scaled based on actual dependency.
Critical Cloud / Production Supplier
Review:
- Security assurance
- Production access
- Customer data
- Availability
- Backup
- Recovery
- Incidents
- Vulnerabilities
- Subprocessors
- Data location
- Exit strategy
Critical SaaS Supplier
Review:
- Customer/personal data
- Authentication
- Access
- Integration
- Availability
- Security assurance
- Incidents
- Subprocessors
- Contract
- Exit/data portability
Critical Security Provider
Review:
- Security data
- Privileged access
- Monitoring
- Incident handling
- Availability
- Confidentiality
- Subprocessors
- Assurance
- Access revocation
The review should remain proportionate to actual risk.
37. Review Frequency
The organization should define frequency based on:
- Supplier criticality
- Information sensitivity
- Production access
- Customer impact
- Regulatory requirements
- Incident history
- Supplier performance
- Dependency
- Concentration
- Assurance
- Contractual requirements
Example model:
| Supplier Risk | Example Review |
|---|---|
| High | Formal periodic review |
| Critical | Enhanced periodic + event-driven review |
These are example organizational approaches, not universal ISO-mandated frequencies.
38. Common Mistakes
Avoid:
- Treating every critical supplier review as a checklist-only exercise
- Checking only certifications
- Ignoring actual service dependency
- Ignoring production access
- Ignoring privileged access
- Ignoring customer data
- Ignoring subprocessors
- Ignoring data location
- Ignoring concentration risk
- Ignoring recovery capability
- Ignoring exit feasibility
- Ignoring unresolved findings
- Not reviewing supplier incidents
- Not reassessing risk after material changes
- Treating contract renewal as the only review trigger
- Closing findings without evidence
- Not obtaining management approval for significant residual risks
39. Internal Audit Checklist
An auditor should be able to verify:
- Supplier is classified as critical
- Criticality rationale is documented
- Critical service is identified
- Business dependency is documented
- Information handled is identified
- Customer data assessed
- Personal data assessed
- Production access reviewed
- Privileged access reviewed
- Security controls reviewed
- Assurance evidence reviewed
- Vulnerability management reviewed
- Incidents reviewed
- BCP/DR reviewed
- Recovery testing reviewed
- Subprocessors reviewed
- Data locations reviewed
- Material changes reviewed
- Contract reviewed
- Concentration risk assessed
- Alternative/exit arrangements assessed
- Corrective actions reviewed
- Current risk reassessed
- Residual risk documented
- Required treatment defined
- Approval recorded
- Evidence retained
- Next review date established
40. Relationship With Other ISMS Documents
The Critical Supplier Review should connect with:
Critical Supplier Register
→ identifies suppliers requiring enhanced oversight.
Supplier Register
→ maintains the complete supplier population.
Supplier Risk Assessment
→ provides the detailed risk assessment.
Supplier Monitoring Register
→ tracks ongoing monitoring.
Supplier Security Evidence Review Checklist
→ evaluates supplier assurance evidence.
Supplier Corrective Action Register
→ tracks findings and remediation.
Supplier Change Assessment
→ evaluates material supplier changes.
ICT Dependency Register
→ documents technology and business dependencies.
Supply Chain Risk Assessment
→ evaluates broader supply-chain risks.
Business Continuity / Disaster Recovery
→ addresses resilience and recovery requirements.
Risk Register
→ records significant organizational risks.
Supplier Offboarding Checklist
→ manages secure supplier termination if required.
41. ISO 27001 Connection
Critical supplier reviews support a risk-based approach to managing externally provided products, services, and dependencies that may affect information security.
The depth of review should be determined by:
- Supplier risk
- Information handled
- Access
- Business criticality
- Customer impact
- Technology dependency
- Legal/regulatory requirements
- Contractual requirements
- Business continuity requirements
- Applicable ISMS controls
- Statement of Applicability
The Critical Supplier Review Template itself is not a universally mandatory ISO 27001 document.
It is an organizational mechanism for demonstrating that critical supplier relationships are periodically evaluated and that changes in security, privacy, availability, dependency, and risk are identified and addressed.
42. Final Audit Trail
The complete critical supplier review trail should be:
Critical Supplier Identified
↓
Criticality Confirmed
↓
Critical Service & Dependency Identified
↓
Information & Access Reviewed
↓
Security Controls Reviewed
↓
Assurance Evidence Reviewed
↓
Incidents & Vulnerabilities Reviewed
↓
Privacy & Subprocessors Reviewed
↓
Availability & BCP/DR Reviewed
↓
Changes & Concentration Risk Reviewed
↓
Contract & Exit Arrangements Reviewed
↓
Corrective Actions Reviewed
↓
Risk Reassessed
↓
Residual Risk Determined
↓
Treatment / Acceptance Defined
↓
Management Approval
↓
Monitoring Continued
↓
Next Review / Event-Driven Review
Final Principle
A critical supplier review should answer:
Why is this supplier critical?
What business service depends on it?
What information and systems are exposed?
Does the supplier still meet our security requirements?
What has changed since the last review?
Can the supplier continue to support us during disruption?
What risks remain?
What corrective actions or additional controls are required?
Who approved the remaining risk?
The objective is not simply to prove that a critical supplier was “reviewed.”
The objective is to demonstrate that the organization continuously understands and manages its critical supplier dependency, security exposure, resilience, and residual risk.