ISO 27001 Annex A 5.22 Monitoring, review and change management of supplier services

ISO/IEC 27001:2022 Annex A 5.22 – Monitoring, Review and Change Management of Supplier Services focuses on ensuring that information security remains appropriately managed when an organization uses services provided by suppliers.

Supplier relationships do not end after a contract is signed.

A supplier may:

Change its infrastructure
Introduce new subprocessors
Change data locations
Modify security controls
Change its service architecture
Experience security incidents
Modify its authentication mechanisms
Change its business continuity arrangements
Acquire or merge with another company
Change service levels
Introduce new technologies

These changes can affect the organization’s information security risk.

The objective of A.5.22 is therefore to ensure that supplier services are regularly monitored and reviewed, and that significant changes are appropriately managed.

What Is ISO 27001 Annex A 5.22?

A.5.22 requires organizations to establish processes for:

Monitoring supplier services
Reviewing supplier performance and security
Managing relevant supplier changes

The organization should verify that suppliers continue to meet agreed information security requirements.

This control applies throughout the supplier relationship, not only during supplier onboarding.

A useful lifecycle is:

Supplier Selection
       ↓
Contract
       ↓
Onboarding
       ↓
Service Delivery
       ↓
Monitoring
       ↓
Periodic Review
       ↓
Change Assessment
       ↓
Corrective Action
       ↓
Renewal / Exit

Why Is A.5.22 Important?

A supplier may be secure when the relationship begins but become a different risk over time.

For example:

A SaaS provider initially stores customer data in an approved region. Later, the provider changes its hosting architecture or introduces a new subprocessor.

If the organization does not monitor supplier changes, it may not identify the new security or compliance implications.

Common Supplier Risks

1. Security control deterioration

A supplier may change its security practices or controls.

2. Service outages

A supplier may experience repeated availability problems.

3. Security incidents

A supplier or its subprocessor may experience a data breach or cyberattack.

4. Subprocessor changes

A supplier may introduce a new third party that processes organizational information.

5. Data-location changes

Information may be moved to a different country, region, cloud platform, or data center.

6. Technology changes

A supplier may introduce a new platform, architecture, AI service, or integration.

7. Ownership changes

A merger or acquisition can materially change the supplier’s risk profile.

8. Contractual changes

Changes to terms, service levels, security commitments, or data-processing arrangements may require review.

What Types of Suppliers Should Be Monitored?

A.5.22 is relevant to suppliers that provide services affecting information security or information processing.

Examples include:

Supplier	Example
Cloud provider	AWS, Azure, Google Cloud
SaaS provider	CRM, HR, ticketing platform
Security provider	MDR, SOC, SIEM
Payment provider	Payment processing
IT provider	Managed IT services
Software vendor	Enterprise software
Development partner	Outsourced software development
Data processor	Customer/employee data processing
Backup provider	Cloud backup
Hosting provider	Website/application hosting
Network provider	Connectivity services
Data center	Colocation
HR provider	Payroll/recruitment systems
Security testing firm	VAPT/penetration testing
Certification/audit provider	ISO/SOC assessment services

Not every supplier requires the same level of monitoring. The approach should be risk-based.

Supplier Monitoring vs Supplier Review vs Change Management

These three activities are related but different.

Activity	Main Question
Monitoring	Is the supplier currently delivering the expected service and security controls?
Review	Does the supplier continue to meet our security and business requirements?
Change Management	Has something changed that could alter the supplier risk?

For example:

Monitoring: The supplier’s uptime and security alerts are monitored.

Review: The organization reviews the supplier’s SOC 2 report annually.

Change Management: The supplier announces a new subprocessor and the organization assesses its impact.

What Should Be Monitored?

The organization should determine monitoring requirements based on supplier risk.

Possible areas include:

Security performance

Security incidents
Vulnerability management
Security certifications
Audit reports
Control effectiveness
Security notifications

Service performance

Availability
SLA performance
Incident response
Support response
Service outages

Data protection

Data location
Data processing
Encryption
Access controls
Retention
Data deletion

Compliance

Regulatory changes
Certification status
Contractual requirements
Privacy obligations

Supplier changes

Subprocessors
Infrastructure
Ownership
Technology
Service scope
Data locations

Supplier Monitoring Frequency

Not every supplier needs to be reviewed every month.

A risk-based model can be used.

Supplier Risk	Example	Review Frequency
Critical	Cloud provider hosting production data	Continuous/quarterly + annual review
High	SaaS processing sensitive information	Quarterly/annual
Medium	Business application	Annual
Low	Office supplies	As appropriate

The actual frequency should be defined by the organization’s risk assessment.

How to Implement ISO 27001 A.5.22

Step 1 – Maintain a Supplier Register

Maintain an inventory of relevant suppliers.

Example:

Supplier	Service	Data	Criticality	Owner	Review Date
Cloud Provider	Infrastructure	Customer Data	Critical	CTO	Dec 2026
HR SaaS	HR Management	Employee Data	High	HR	Nov 2026
Payment Provider	Payments	Transaction Data	High	Finance	Jan 2027
Office SaaS	Productivity	Internal Data	Medium	IT	Mar 2027

The supplier register should identify which suppliers require ongoing monitoring.

Step 2 – Classify Supplier Risk

Consider factors such as:

Data sensitivity
Service criticality
Privileged access
Production access
Business dependency
Regulatory impact
Number of users
Geographic exposure
Subprocessor dependency
Availability requirements

For example:

Critical supplier

A cloud provider hosting the organization’s production application.

High-risk supplier

A SaaS platform processing customer personal information.

Lower-risk supplier

A supplier providing non-sensitive office services.

Step 3 – Define Monitoring Requirements

The organization should establish what evidence or information it expects from important suppliers.

Examples:

SOC 2 report
ISO 27001 certificate
Penetration-test summary
Vulnerability management evidence
Business continuity information
Security incident notifications
Availability reports
SLA reports
Subprocessor list
Data-location information

The exact evidence should depend on supplier risk.

Step 4 – Monitor Supplier Performance

Monitor relevant supplier metrics.

Examples:

Availability

Monthly uptime: 99.95%
SLA requirement: 99.90%
Status: Meets requirement

Security incidents

Supplier incidents this period: 0

Support

Critical tickets:
Response SLA: 1 hour
Actual average: 35 minutes

The organization should define meaningful metrics rather than collecting large amounts of unnecessary information.

Step 5 – Conduct Periodic Supplier Reviews

Important suppliers should undergo periodic review.

A review may consider:

Security performance
SLA performance
Incidents
Audit reports
Certifications
Vulnerabilities
Compliance
Changes
Business continuity
Subprocessors
Contract compliance

The outcome should be documented.

Step 6 – Monitor Supplier Security Evidence

For important suppliers, periodically check whether security certifications and assurance reports remain valid.

Examples:

ISO 27001 certificate
SOC 2 Type II report
PCI DSS compliance
Independent security assessment

Do not simply collect certificates.

Review:

Scope
Validity
Expiration
Exceptions
Relevant findings
Applicability to your service

Step 7 – Monitor Supplier Changes

Organizations should define how supplier changes are identified.

Sources can include:

Supplier notifications
Security advisories
Contract notices
Subprocessor pages
Release communications
Account managers
Service status pages
Security bulletins
Audit reports

Important changes should trigger an assessment.

What Supplier Changes Should Trigger Review?

Examples include:

Technology changes

New hosting platform
New architecture
New authentication system
New API
New AI capability

Data changes

New data category
New processing purpose
New data location
New retention period

Organizational changes

Merger
Acquisition
Ownership change
Major restructuring

Supplier changes

New subprocessor
New subcontractor
Change in service provider
Outsourcing of service

Security changes

Security incident
Major vulnerability
Loss of certification
Significant audit finding

Contract changes

SLA changes
Security requirement changes
Liability changes
Data-processing changes

Step 8 – Assess Supplier Change Impact

When a significant change occurs, determine whether it affects the organization’s risk.

For example:

Supplier announcement:

“Customer data processing will now be supported by a new subprocessor.”

Questions:

What information will the subprocessor access?
Where is it located?
What security controls apply?
Is the subprocessor contractually bound?
Does this affect privacy requirements?
Does the organization’s risk assessment need updating?
Is customer notification required?
Does the contract permit the change?

Step 9 – Take Corrective Action

If a supplier fails to meet requirements, define an appropriate response.

Possible actions:

Request corrective action
Establish remediation deadline
Increase monitoring
Conduct additional assessment
Escalate to management
Restrict supplier access
Suspend certain activities
Renegotiate requirements
Consider alternative suppliers

The response should be proportionate to the risk.

Step 10 – Maintain Evidence

Keep evidence showing that suppliers are actually being monitored and reviewed.

Examples:

Supplier review records
SLA reports
Security reports
SOC 2 reports
ISO certificates
Incident records
Change notifications
Subprocessor reviews
Corrective action plans
Management review records

Example – SaaS Startup

Consider a SaaS startup using a cloud provider to host its application.

The cloud provider is critical because:

Production systems depend on it.
Customer data is processed there.
Business availability depends on it.
Security controls are partly dependent on the provider.

The startup establishes:

Quarterly

Review service incidents
Review availability
Review major security notifications
Review important supplier changes

Annually

Review independent assurance reports
Review certification status
Reassess supplier risk
Review contractual requirements
Confirm business continuity information

Event-driven

Review immediately when:

Major security incident occurs
New subprocessor is introduced
Data location changes
Service architecture changes
Supplier is acquired
Certification expires or changes

This provides a practical implementation of A.5.22.

Supplier Change Management Workflow

A simple process can be:

Supplier Change Identified
          ↓
Change Logged
          ↓
Impact Assessment
          ↓
Security / Privacy Review
          ↓
Risk Updated?
     ┌────┴────┐
    Yes        No
     ↓          ↓
Risk Treatment  Record Decision
     ↓
Approval
     ↓
Contract / Controls Updated
     ↓
Supplier Monitoring
     ↓
Close

Example – New Subprocessor

Suppose a SaaS supplier announces:

A new third party will provide customer-support infrastructure.

The organization should consider:

What information will be shared?
Is personal information involved?
Where will processing occur?
What security controls does the subprocessor maintain?
Is the subprocessor covered by the supplier’s contractual obligations?
Does the organization need to update its privacy assessment?
Does the change affect the supplier’s risk rating?
Is customer notification required under applicable terms?
Should additional controls be introduced?

The decision and rationale should be documented.

Supplier Review Scorecard

A simple review can be structured as follows:

Area	Result	Comments
Security controls	Satisfactory	Current assurance report
Availability	Satisfactory	SLA met
Incidents	Review required	One security incident
Compliance	Satisfactory	Certification valid
Subprocessors	Review required	New subprocessor
Data location	Satisfactory	No change
Contract	Satisfactory	Current
Overall risk	Review	Follow-up required

This should support a documented risk decision rather than simply generating a numerical score.

What Events Should Trigger Supplier Review?

Trigger	Action
Annual review date	Perform scheduled review
Security incident	Immediate review
New subprocessor	Assess impact
Data-location change	Review security/privacy implications
Major service outage	Review supplier performance
Certification expiry	Obtain updated evidence
New certification/report	Review assurance
Contract renewal	Review requirements
Supplier acquisition	Reassess supplier risk
Major architecture change	Review security impact
New service	Assess new risks
Regulatory change	Review compliance requirements
Customer security requirement	Reassess controls

Startup Quick Summary

A startup does not need to monitor every supplier in the same way.

Focus first on suppliers that:

Process sensitive information
Host production systems
Have privileged access
Are critical to business operations
Affect regulatory obligations
Have significant customer impact

For these suppliers:

Monitor → Review → Identify Changes → Assess Impact → Act → Document

Minimum Startup Implementation

A startup should establish at least:

1. Supplier register

Identify important suppliers and their owners.

2. Supplier risk classification

Identify critical and high-risk suppliers.

3. Monitoring requirements

Define what needs to be monitored.

4. Periodic review

Review important suppliers at defined intervals.

5. Security evidence

Track relevant ISO 27001, SOC 2, PCI DSS or other assurance evidence.

6. Change notifications

Monitor supplier changes, including subprocessors and data locations.

7. Incident monitoring

Track supplier security incidents and service disruptions.

8. Corrective actions

Track supplier issues until resolved.

9. Risk reassessment

Update supplier risk when significant changes occur.

10. Documentation

Maintain evidence of monitoring and review activities.

Supplier Monitoring Register

A practical register can look like:

Supplier	Service	Risk	Monitoring	Review Frequency	Owner	Last Review	Next Review
Cloud Provider	Hosting	Critical	SLA + Security	Quarterly	CTO	Sep 2026	Dec 2026
HR SaaS	HR Data	High	Security + Privacy	Annual	HR	Jan 2026	Jan 2027
Payment Provider	Payments	High	SLA + Compliance	Annual	Finance	Mar 2026	Mar 2027
Productivity SaaS	Collaboration	Medium	Security	Annual	IT	Jun 2026	Jun 2027

Supplier Change Register

Organizations can separately track significant supplier changes.

Change ID	Supplier	Change	Date	Security Impact	Review	Action	Status
SCM-001	Cloud Provider	New region	Sep 2026	Medium	Completed	Risk updated	Closed
SCM-002	SaaS Vendor	New subprocessor	Sep 2026	High	Completed	Privacy review	Closed
SCM-003	Security Provider	New monitoring platform	Aug 2026	Medium	Completed	Contract updated	Closed

Audit Evidence for A.5.22

An auditor may look for:

Supplier management

Supplier register
Supplier risk assessments
Critical supplier list
Supplier owners

Monitoring

SLA reports
Service reports
Security notifications
Incident records
Performance reports

Reviews

Periodic supplier reviews
Review meeting records
Assurance reports
ISO certificates
SOC reports
Security assessments

Change management

Supplier change notifications
Subprocessor reviews
Data-location assessments
Architecture change assessments
Contract amendments

Corrective actions

Supplier findings
Remediation plans
Follow-up records
Escalations

ISO 27001 A.5.22 Audit Checklist

#	Audit Question	Evidence
1	Is there a supplier register?	Supplier register
2	Are suppliers classified according to risk?	Supplier risk assessment
3	Are critical suppliers identified?	Critical supplier list
4	Are supplier services monitored?	Monitoring records
5	Are supplier security requirements periodically reviewed?	Review records
6	Are supplier assurance reports reviewed?	SOC/ISO reports
7	Are supplier incidents monitored?	Incident records
8	Are significant supplier changes identified?	Change notifications
9	Are new subprocessors reviewed?	Subprocessor assessment
10	Are changes in data location reviewed?	Data-location assessment
11	Are supplier changes risk-assessed?	Change assessment
12	Are supplier issues tracked to resolution?	Corrective action records
13	Are supplier contracts updated when necessary?	Contract amendments
14	Are reviews performed at defined intervals?	Review schedule
15	Is monitoring adjusted when supplier risk changes?	Updated risk assessment

Common Mistakes

Mistake 1 – Supplier review only happens during onboarding

Supplier risk can change significantly after onboarding.

A.5.22 requires an ongoing approach.

Mistake 2 – Collecting certificates without reviewing them

A certificate alone does not demonstrate that the supplier continues to meet your specific requirements.

Check:

Scope
Validity
Expiry
Relevant controls
Exceptions
Findings where available

Mistake 3 – Ignoring subprocessors

A supplier may rely on several other organizations.

Changes in subprocessors can affect your information security and privacy risks.

Mistake 4 – No process for supplier notifications

If a supplier announces a major change, someone should be responsible for reviewing it.

Mistake 5 – Monitoring only SLA performance

Supplier monitoring should consider security as well as availability and service quality.

Mistake 6 – Same review frequency for every supplier

A critical cloud provider should generally receive more attention than a low-risk office supplier.

Mistake 7 – No evidence of review

Informal conversations are difficult to demonstrate during an audit.

Maintain appropriate records.

Policy vs Process vs Technical Control

Area	Example
Policy	Critical supplier services must be monitored and reviewed
Procedure	Define supplier monitoring, review and change assessment
Process Control	Periodic supplier review
Technical Control	Monitoring, alerts, access and logging
Contractual Control	Security, incident and change-notification clauses
Evidence	Review records, assurance reports and change assessments

Relationship With Other ISO 27001 Controls

A.5.22 works closely with several supplier controls:

Control	Relationship
A.5.19 Information Security in Supplier Relationships	Establishes security processes for supplier relationships
A.5.20 Addressing Information Security Within Supplier Agreements	Defines security requirements in supplier contracts
A.5.21 Managing Information Security in the ICT Supply Chain	Addresses ICT supply-chain security
A.5.22 Monitoring, Review and Change Management of Supplier Services	Ensures supplier security remains appropriately managed over time
A.5.23 Information Security for Use of Cloud Services	Addresses security for cloud services
A.5.31 Legal, Statutory, Regulatory and Contractual Requirements	Supports ongoing compliance obligations
A.8.30 Outsourced Development	Relevant where software development is outsourced

A.5.19 vs A.5.20 vs A.5.21 vs A.5.22

These controls can be understood as a supplier lifecycle:

Control	Main Focus
A.5.19	How supplier relationships are managed securely
A.5.20	What security requirements are included in agreements
A.5.21	Security across the ICT supply chain
A.5.22	How supplier services are monitored, reviewed and changed

A simple model is:

Select securely → Contract securely → Manage the supply chain → Monitor continuously

Practical Implementation Model

                 SUPPLIER ONBOARDING
                         |
                         v
                  RISK CLASSIFICATION
                         |
                         v
                 SECURITY REQUIREMENTS
                         |
                         v
                       CONTRACT
                         |
                         v
                  SERVICE DELIVERY
                         |
             +-----------+-----------+
             |                       |
             v                       v
         MONITORING              CHANGES
             |                       |
             v                       v
        PERIODIC REVIEW        IMPACT ASSESSMENT
             |                       |
             +-----------+-----------+
                         |
                         v
                   CORRECTIVE ACTION
                         |
                         v
                  RISK REASSESSMENT
                         |
                         v
                   CONTINUE / EXIT

Useful Resources

Organizations implementing A.5.22 may benefit from maintaining:

Final Takeaway

ISO 27001 Annex A 5.22 is about ensuring that supplier security does not become a “set it and forget it” activity.

A supplier may change its technology, infrastructure, subprocessors, ownership, data locations, services or security posture during the relationship.

A practical implementation is:

Monitor supplier services → Review performance and security → Identify significant changes → Assess their impact → Take action → Maintain evidence.

For startups, the most important step is to focus monitoring effort on critical and high-risk suppliers rather than applying the same level of effort to every vendor.

The goal is simple:

Know what your important suppliers are doing, know when they change, understand how those changes affect your risk, and act when necessary.