Supplier Change Assessment Template

1. Purpose

The Supplier Change Assessment Template is used to evaluate changes proposed, announced, or implemented by suppliers that may affect the organization’s information security, privacy, technology, business operations, customers, compliance obligations, or contractual requirements.

The assessment helps determine whether a supplier change:

Can proceed without additional action
Requires security or privacy controls
Requires risk reassessment
Requires contractual changes
Requires management approval
Requires testing or validation
Requires contingency planning
Should be rejected or postponed

The assessment follows:

Supplier → Change → Impact → Risk → Controls → Approval → Implementation → Validation → Reassessment

2. When to Use This Template

Use this assessment when a supplier change could materially affect the organization’s:

Information
Customer data
Personal data
Production systems
Technology
Access
Security controls
Business continuity
Service availability
Regulatory obligations
Contractual commitments
Supplier risk

Examples include:

New supplier service
Major service modification
Cloud migration
Infrastructure change
Authentication change
New API/integration
New subprocessor
Data-location change
Ownership change
Security-control change
Production-access change
Product retirement
Material SLA change
Contractual security change

Minor administrative changes may not require a full assessment.

3. Assessment Record

Field	Details
Assessment ID	SCA-001
Change ID	CHG-001
Supplier ID	SUP-001
Supplier Name
Supplier Type
Service
Supplier Criticality	Low / Medium / High / Critical
Business Owner
Supplier Owner
Assessment Date
Change Notification Date
Proposed Change Date
Change Status	Proposed / In Progress / Implemented
Assessment Lead
Security Reviewer
Privacy Reviewer	If applicable
Business Reviewer
Risk Reviewer	If applicable

4. Change Description

Describe the supplier’s proposed or actual change.

Change Title

Example: Migration of customer-support platform to new hosting infrastructure

Current State

Describe how the supplier currently provides the service.

Proposed State

Describe what will change.

Reason for Change

Examples:

Technology modernization
Security improvement
Product upgrade
Business restructuring
New service
Regulatory requirement
Performance improvement
End-of-life technology
Supplier acquisition

Effective Date

Record the planned or actual implementation date.

5. Change Classification

Select the applicable change type.

Service change
Technology change
Infrastructure change
Cloud change
Application change
API/integration change
Security-control change
Authentication change
Access change
Data-processing change
Data-location change
Subprocessor change
Ownership change
Organizational change
Contractual change
SLA change
Product retirement
Business continuity change
Other

6. Change Classification by Impact

Classify the overall change.

Low

Minimal effect on security, information, business operations, or customers.

Medium

Potential effect requiring documented assessment and appropriate controls.

High

Significant effect on information, systems, access, privacy, security, or business dependency.

Critical

Potential material impact on critical business services, sensitive information, customers, security, regulatory obligations, or production operations.

Assessment Result:

Low / Medium / High / Critical

The classification should follow the organization’s approved risk/change methodology.

7. Business Impact Assessment

Assess the effect on business operations.

Question	Yes/No/N/A	Comments
Does the change affect a business-critical service?
Does it affect customer-facing services?
Could availability be affected?
Could service performance be affected?
Could revenue-generating activities be affected?
Does it affect business continuity?
Does it affect recovery arrangements?
Does it create a new dependency?
Does it increase supplier dependency?
Does it create concentration risk?
Is an alternative supplier available?
Is migration/exit capability affected?

Business Impact Summary

Describe the expected business impact and identify any required continuity or contingency measures.

8. Information Impact Assessment

Identify information affected by the change.

Information Type	Applicable?	Classification	Impact
Public information
Internal information
Confidential information
Restricted information
Customer information
Personal data
Financial information
Authentication information
Source code
Security information
Other sensitive information

Consider:

Confidentiality
Integrity
Availability
Data ownership
Data retention
Data deletion
Data transfer

9. Customer Data Assessment

Determine whether customer information is affected.

No customer data
Customer data stored
Customer data processed
Customer data transmitted
Customer data accessed
Customer-facing service affected

Customer Impact

Document:

Customers affected
Type of information
Expected impact
Customer notification requirements
Contractual commitments
Service commitments

10. Personal Data Assessment

Where personal data is involved, assess:

Area	Assessment
Personal data involved	Yes / No
Data categories
Data subjects
Processing purpose
Processing location
New processing activity	Yes / No
New subprocessor	Yes / No
Cross-border transfer	Yes / No
Retention affected	Yes / No
Deletion affected	Yes / No
DPA affected	Yes / No
Privacy assessment required	Yes / No

Where required, involve the organization’s privacy/legal function.

11. Data Location Assessment

Determine whether the change affects where information is stored or processed.

Current Location

Proposed Location

Change

No change
New hosting location
New processing location
New backup location
Cross-border transfer
New subprocessor location

Assessment

Consider:

Legal requirements
Privacy requirements
Customer commitments
Contractual requirements
Data residency
Security implications

12. Subprocessor Assessment

Determine whether the supplier is introducing or changing subprocessors.

Question	Yes/No/N/A	Comments
Is a new subprocessor involved?
Is an existing subprocessor being replaced?
Will the subprocessor process personal data?
Will customer data be involved?
Is the processing location changing?
Is security assurance available?
Is customer notification required?
Is DPA review required?
Is supplier risk reassessment required?

13. Technology Impact Assessment

Identify affected technology.

Cloud infrastructure
SaaS application
IaaS/PaaS
Database
API
Network
Identity system
Authentication
Source-code repository
CI/CD
Security tooling
Backup
Monitoring
Endpoint
Other

Affected Systems

System/Application	Environment	Impact
	Production / Test / Development
	Production / Test / Development

14. Security Control Impact Assessment

Assess whether the change affects existing security controls.

Security Area	Impact?	Assessment
Authentication	Yes/No
MFA	Yes/No
Authorization	Yes/No
Privileged access	Yes/No
Encryption	Yes/No
Key management	Yes/No
Logging	Yes/No
Monitoring	Yes/No
Vulnerability management	Yes/No
Network security	Yes/No
Backup	Yes/No
Recovery	Yes/No
Incident response	Yes/No
Data protection	Yes/No
Security testing	Yes/No

15. Supplier Access Assessment

Determine whether supplier access changes.

Access Type	Current	Proposed	Impact
Standard access
Production access
Privileged access
Cloud access
Database access
Source-code access
API access
Remote access

Consider:

Named accounts
MFA
Least privilege
Role-based access
Temporary access
Logging
Access approval
Access review
Account removal

16. Authentication and Identity Assessment

If authentication changes, assess:

MFA
SSO
Identity federation
Password requirements
Session management
Account recovery
Privileged authentication
Service accounts
API authentication
Logging
Access provisioning/deprovisioning

Result

17. Availability and Business Continuity Assessment

Assess whether the supplier change affects:

Service availability
SLA
RTO
RPO
Backup
Disaster recovery
Failover
Redundancy
Recovery testing
Alternative suppliers
Migration capability

Continuity Impact

Contingency Required?

If yes:

18. Contractual Assessment

Review whether the change affects the supplier agreement.

Contract Area	Affected?	Action
Security requirements
Privacy requirements
DPA
Incident notification
Audit rights
Assurance requirements
Subprocessors
Data location
Data deletion
Data return
SLA
Business continuity
Termination
Exit assistance

Legal/procurement review should be obtained where appropriate.

19. Compliance Assessment

Determine whether the change affects applicable:

Laws
Regulations
Industry requirements
Customer commitments
Contractual requirements
Internal policies
Security certifications
Audit commitments

Applicable Requirements

Compliance Impact

20. Security Assurance Assessment

Determine whether existing supplier assurance remains relevant.

Review, where applicable:

ISO 27001 certification
SOC 1 report
SOC 2 report
Penetration-test report
Independent assessment
Security questionnaire
BCP/DR evidence
Privacy assessment

Consider whether the change:

Falls outside the assurance scope
Changes the service covered
Changes the processing location
Changes the security architecture
Makes existing evidence outdated

21. Vulnerability Assessment

Determine whether the change introduces new vulnerability exposure.

Consider:

New technologies
New APIs
New software
New infrastructure
New integrations
New dependencies
Unsupported components
Security advisories
Configuration changes

Vulnerability Assessment Result

Where appropriate, connect the assessment to the organization’s vulnerability-management process.

22. Threat Assessment

Identify realistic threats associated with the change.

Examples:

Unauthorized access
Data exposure
Credential compromise
Misconfiguration
Supply-chain compromise
Service outage
Data leakage
Privilege escalation
API abuse
Loss of availability
Inadequate monitoring

Threats Identified

23. Risk Assessment

Evaluate the risk resulting from the change.

Risk Scenario

Because of [change], [threat/vulnerability] could result in [impact].

Likelihood

Low / Medium / High

Impact

Low / Medium / High

Inherent Risk

Low / Medium / High / Critical

Existing Controls

Residual Risk

Low / Medium / High / Critical

The organization’s approved risk methodology should be used for the actual rating.

24. Risk Treatment

If additional treatment is required, document it.

Risk	Treatment	Control/Action	Owner	Due Date
	Mitigate / Avoid / Transfer / Accept

Examples:

Enable MFA
Restrict production access
Conduct security testing
Update DPA
Obtain assurance evidence
Add contractual requirement
Implement monitoring
Create backup
Establish alternative supplier
Perform additional review

25. Change Approval Conditions

Document any conditions attached to approval.

Example:

Change approved subject to:

MFA validation

Security testing

Updated DPA

Access review

Post-change validation

Conditions

26. Approval Decision

Select one:

Approved
Approved with Conditions
Further Assessment Required
Deferred
Rejected
Emergency Approval
Accepted as Existing Risk

Approval Comments

27. Implementation Requirements

Before implementation, identify required actions.

Action	Owner	Due Date	Status
Security testing
Privacy review
Contract update
Access review
Backup/contingency
Technical testing
Customer notification

28. Post-Change Validation

After implementation, verify:

Service operates correctly
Security controls operate correctly
MFA works
Access is appropriate
Privileged access is controlled
Logging works
Monitoring works
Data flows are correct
Encryption remains effective
Backup/recovery remains effective
Integrations work
Privacy requirements remain satisfied
SLA/service requirements remain satisfied
No unexpected security issue identified

Validation Evidence

29. Post-Change Risk Reassessment

After implementation, determine whether the actual outcome differs from the original assessment.

Item	Before Change	After Change
Risk
Security controls
Access
Availability
Data processing
Supplier dependency

Final Risk

Low / Medium / High / Critical

Risk Changed?

No
Increased
Reduced
New risk identified

30. Related ISMS Records Updated

Select applicable records:

Supplier Register
Critical Supplier Register
Supplier Monitoring Register
Supplier Risk Assessment
ICT Dependency Register
Software Dependency Inventory
Asset Register
Access Register
Data Inventory
RoPA
DPA
Supplier Contract
Risk Register
Business Continuity documentation
Architecture documentation
Security requirements
Other

31. Evidence Register

Evidence ID	Evidence	Source
EV-001	Supplier change notification	Supplier
EV-002	Security assessment	Security
EV-003	Risk assessment	Risk
EV-004	Approval	Management
EV-005	Post-change validation	IT/Security

Do not store passwords, API keys, private keys, tokens, or other secrets in this template.

32. AWS SaaS Example

Consider a SaaS company hosted on AWS.

A critical supplier announces that it will change the authentication platform used by the company’s customer-support system.

Change

Supplier: Customer-support SaaS provider
Change: Authentication architecture migration
Criticality: High
Affected information: Customer support tickets and user identity information

Assessment

The organization determines:

SSO integration will change
MFA must remain available
Supplier administrative access is affected
API authentication may change
Authentication logs must remain available
Customer data remains within the same approved processing arrangement

Risk

Potential loss of authentication security or unauthorized access if the new authentication mechanism is incorrectly configured.

Treatment

Validate MFA
Test SSO
Review privileged access
Validate logging
Test account recovery
Review supplier security documentation

Post-Change

Security and IT validate the new authentication flow and retain test evidence.

The Supplier Change Assessment is then updated with the final result and residual risk.

33. Critical Supplier Change Assessment

For critical suppliers, consider additional questions.

Does the change affect a critical business service?
Does it increase supplier dependency?
Does it create concentration risk?
Does it reduce resilience?
Is an alternative provider available?
Is migration possible?
Does the change affect RTO/RPO?
Does it affect customer commitments?
Does it affect regulatory obligations?
Does it affect production infrastructure?
Does it affect privileged access?
Does it affect sensitive information?
Does it require management approval?
Is contingency planning required?

34. Emergency Change Assessment

Where immediate action is required because of:

Critical vulnerability
Active exploitation
Security incident
Major outage
Infrastructure failure
Emergency security patch

the assessment may be completed using an expedited process.

At minimum, record:

Reason for emergency
Change
Immediate risk
Decision maker
Required controls
Implementation
Validation
Post-change review

Emergency processing should not eliminate documentation.

35. Roles and Responsibilities

Supplier Owner

Initiates/coordinates assessment
Obtains supplier information
Maintains assessment record
Tracks actions

Business Owner

Assesses business impact
Confirms business requirements
Approves business impact where applicable

Information Security

Assesses security impact
Reviews controls
Evaluates security risk
Defines security requirements

IT/Engineering

Assesses technical impact
Performs technical testing
Validates implementation

Privacy

Where applicable:

Reviews personal-data impact
Assesses subprocessors
Reviews data-location changes

Legal/Procurement

Where applicable:

Reviews contract changes
Reviews contractual security/privacy obligations

Risk Owner

Reviews significant risk
Approves risk treatment or acceptance

36. Common Mistakes

Mistake 1: Treating supplier changes as simple notifications

A notification does not tell you whether the change affects your risk.

Better: Assess the actual impact.

Mistake 2: Only assessing technology

A technical change may also affect:

Privacy
Contracts
Customers
Business continuity
Compliance

Better: Use a multidisciplinary impact assessment where necessary.

Mistake 3: Ignoring data-location changes

Moving data between regions can have significant contractual or privacy implications.

Better: Always assess material data-location changes.

Mistake 4: Ignoring supplier access

A supplier change may introduce new administrative or production access.

Better: Explicitly assess access changes.

Mistake 5: No post-change validation

Approval does not prove successful implementation.

Better: Validate the actual implemented change.

Mistake 6: Failing to update related records

A change can make supplier, risk, dependency, or privacy records inaccurate.

Better: Update all affected ISMS records.

37. Internal Audit Checklist

An auditor may verify:

Supplier changes are identified
Material changes are assessed
Change description is documented
Business impact is assessed
Information impact is assessed
Customer impact is considered
Personal-data impact is assessed where applicable
Subprocessors are assessed
Data-location changes are reviewed
Technology impact is assessed
Security controls are reviewed
Access changes are assessed
Availability and continuity are considered
Contractual impact is reviewed
Compliance impact is considered
Supplier assurance is reviewed
Risk is assessed
Treatment actions are documented
Approval is recorded
Implementation is validated
Post-change risk is reassessed
Related registers are updated
Evidence is retained
Critical supplier changes receive appropriate additional review
Emergency changes are documented

38. Relationship With Other Supplier Documents

Document	Purpose
Supplier Change Management Procedure	Defines the overall change-management process
Supplier Change Assessment Template	Performs the detailed impact/risk assessment
Supplier Monitoring Register	Tracks ongoing supplier monitoring
Supplier Risk Assessment	Establishes broader supplier risk
Supplier Security Review	Performs periodic supplier review
Critical Supplier Register	Identifies critical suppliers
ICT Dependency Register	Records technology dependencies
Supplier Security Requirements	Defines expected controls
Supplier Contract Security Checklist	Reviews contractual security requirements
DPA Checklist	Reviews applicable privacy requirements
Supplier Offboarding Checklist	Manages supplier termination

39. ISO 27001 Connection

The Supplier Change Assessment Template supports the organization’s risk-based management of supplier relationships and information-security risks.

The assessment can feed into:

Risk assessment
Risk treatment
Statement of Applicability
Supplier management
Access management
Incident management
Vulnerability management
Business continuity
Privacy management
ICT dependency management
Internal audit

The exact assessment requirements should be based on:

Organizational context
Supplier criticality
Information handled
Access provided
Risk assessment
Legal/regulatory requirements
Contractual obligations
Customer requirements
Applicable ISMS controls

This template is an organizational implementation tool. ISO/IEC 27001 does not require this exact form or format.

40. Final Audit Trail

A complete Supplier Change Assessment should demonstrate:

Supplier Change Identified
↓
Change Logged
↓
Change Classified
↓
Business Impact Assessed
↓
Information / Data Impact Assessed
↓
Security / Privacy / Technology Impact Assessed
↓
Supplier Risk Assessed
↓
Controls / Treatment Defined
↓
Approval Obtained
↓
Change Implemented
↓
Post-Change Validation
↓
Residual Risk Confirmed
↓
Supplier / Risk / Dependency Records Updated
↓
Assessment Closed

Final Principle

A Supplier Change Assessment should answer:

What is changing? → Why is it changing? → What does it affect? → What could go wrong? → What controls are required? → Who approved it? → Did the change work as expected? → Has the supplier risk changed?

The objective is not to prevent suppliers from changing. The objective is to ensure that material supplier changes are understood, risk-assessed, appropriately approved, securely implemented, and supported by evidence.