1. Purpose
The Supplier Monitoring Procedure defines how the organization continuously monitors suppliers and periodically reviews their security, privacy, service performance, availability, compliance, access, and risk.
The procedure ensures that supplier risks remain visible and appropriately managed throughout the supplier relationship—not only during onboarding.
The procedure follows this lifecycle:
Supplier → Service → Information → Access → Risk → Requirements → Contract → Monitoring → Review → Reassessment → Treatment → Offboarding
2. Scope
This procedure applies to suppliers that provide products, services, technology, infrastructure, or capabilities that may affect:
- Information security
- Customer information
- Personal data
- Production systems
- Business-critical services
- Cloud infrastructure
- Software and applications
- Network and connectivity
- Identity and authentication
- Backup and recovery
- Security monitoring
- Payment processing
- Development and CI/CD
- Managed services
- Business continuity
- Regulatory or contractual obligations
Examples include:
- Cloud providers
- SaaS providers
- IaaS/PaaS providers
- Software vendors
- Managed service providers
- Security service providers
- Consultants and contractors
- Payment providers
- Backup providers
- Data processors
- Subprocessors
- Technology partners
- Critical infrastructure providers
3. Procedure Principles
Supplier monitoring should be:
Risk-based
The organization should not monitor every supplier in exactly the same way.
Monitoring should consider:
- Supplier criticality
- Information handled
- Customer impact
- Personal-data processing
- Production access
- Privileged access
- Business dependency
- Security risk
- Regulatory requirements
- Contractual requirements
- Availability requirements
- Supplier concentration
- Subprocessor dependency
Evidence-based
Monitoring should rely on available evidence such as:
- Security reports
- Certifications
- SOC reports
- Assessment reports
- Vulnerability information
- Incident notifications
- SLA reports
- Availability reports
- Access reviews
- Security questionnaires
- BCP/DR evidence
- Penetration-testing summaries
- Contract reviews
- Supplier meetings
- Supplier performance reports
Continuous and event-driven
Monitoring should occur through normal operations and should also be triggered when significant events occur.
4. Supplier Monitoring Lifecycle
The monitoring process should follow:
1. Identify Supplier
↓
2. Classify Supplier
↓
3. Identify Monitoring Requirements
↓
4. Perform Ongoing Monitoring
↓
5. Collect Evidence
↓
6. Identify Changes or Issues
↓
7. Assess Risk Impact
↓
8. Create Findings/Actions
↓
9. Reassess Supplier Risk
↓
10. Escalate or Accept Risk
↓
11. Conduct Periodic Review
↓
12. Continue, Modify, or Offboard Supplier
5. Supplier Monitoring Record
Each monitored supplier should have a monitoring record containing, as applicable:
| Field | Description |
|---|---|
| Supplier ID | Unique supplier identifier |
| Supplier Name | Legal/business name |
| Service | Service provided |
| Supplier Type | Cloud, SaaS, consultant, etc. |
| Supplier Criticality | Low/Medium/High/Critical |
| Business Owner | Internal service owner |
| Supplier Owner | Internal supplier-management owner |
| Information Classification | Information handled |
| Customer Data | Yes/No |
| Personal Data | Yes/No |
| Production Access | Yes/No |
| Privileged Access | Yes/No |
| Contract | Contract reference |
| Security Requirements | Applicable requirements |
| Monitoring Frequency | Defined frequency |
| Last Monitoring Date | Most recent monitoring |
| Next Monitoring Date | Planned monitoring |
| Current Risk | Current supplier risk |
| Findings | Open issues |
| Corrective Actions | Required actions |
| Assurance Status | Current evidence/certification |
| Status | Active/Under Review/Restricted/Offboarding |
| Evidence Location | Reference to supporting evidence |
6. Supplier Classification
Before defining monitoring activities, the supplier should be classified.
A practical startup model is:
Low
Limited business or information-security impact.
Example:
- Office stationery supplier
- Non-sensitive marketing service
Medium
Supplier has meaningful business or information-security dependency.
Example:
- Internal productivity SaaS
- HR software
- Marketing platform
High
Supplier handles sensitive information or has important system/business access.
Example:
- Customer-support SaaS
- Payment provider
- Security service provider
- Software development partner
Critical
Failure, compromise, or unavailability could materially affect critical business operations, customers, security, regulatory obligations, or production services.
Example:
- Primary cloud infrastructure provider
- Critical identity provider
- Critical payment platform
- Core production technology provider
The classification should be based on the organization’s risk methodology rather than the supplier’s name alone.
7. Define Monitoring Requirements
For each supplier, determine what should be monitored.
Possible monitoring areas include:
| Monitoring Area | Examples |
|---|---|
| Security | Security incidents, vulnerabilities, control changes |
| Access | User accounts, privileged access, production access |
| Privacy | Data processing, privacy incidents, subprocessors |
| Availability | Uptime, outages, service degradation |
| Performance | SLA/KPI performance |
| Assurance | ISO 27001, SOC reports, assessments |
| Compliance | Regulatory/contractual requirements |
| Incidents | Security incidents and breaches |
| Vulnerabilities | Critical vulnerabilities affecting service |
| Subprocessors | New or changed subprocessors |
| Data Location | Changes in hosting/processing locations |
| Technology | Material architecture or platform changes |
| Continuity | BCP/DR capability and test results |
| Contract | Security obligations and contract changes |
| Concentration | Increased dependency on supplier |
| Exit | Availability of alternative arrangements |
8. Security Monitoring
The organization should monitor relevant security information provided by or concerning the supplier.
This may include:
- Security incidents
- Data breaches
- Major vulnerabilities
- Security advisories
- Material control changes
- Security assessment results
- Penetration-testing summaries
- Certification status
- SOC reports
- Significant audit findings
- Security-related service disruptions
- Changes to security architecture
- Changes to authentication mechanisms
- Changes affecting customer data
Monitoring should be proportionate to supplier risk.
9. Supplier Access Monitoring
Where suppliers have access to organizational systems, access should be periodically reviewed.
The review should consider:
- Is the supplier still providing the service?
- Is access still required?
- Are all users authorized?
- Are individual accounts being used?
- Is MFA enabled where required?
- Does the supplier have privileged access?
- Does the supplier have production access?
- Are inactive accounts removed?
- Are former supplier personnel removed?
- Are temporary accounts expired?
- Are excessive permissions identified?
- Are service accounts still required?
AWS SaaS Example
A development supplier has temporary access to an AWS production environment.
During monitoring, the organization verifies:
- Named supplier accounts
- MFA
- IAM roles
- Least privilege
- Production permissions
- CloudTrail activity
- Temporary access expiry
- Former personnel access
- Security-group or network access
If the supplier no longer requires production access, the access should be removed and evidence retained.
10. Supplier Assurance Monitoring
Supplier assurance evidence should be monitored for validity and relevance.
Examples include:
- ISO 27001 certificate
- SOC 1 report
- SOC 2 report
- Independent security assessment
- Penetration-test summary
- BCP/DR test evidence
- Security questionnaire
- Privacy assessment
- Regulatory assessment
The organization should verify, where relevant:
- Report/certificate scope
- Validity period
- Covered services
- Covered locations
- Exceptions
- Significant findings
- Complementary user entity controls
- Management responses
- Expiration date
A supplier having an ISO 27001 or SOC 2 report does not automatically eliminate the organization’s supplier-specific risk.
11. Certification and Assurance Expiry Monitoring
Supplier certifications and assurance reports should be tracked.
Example:
| Supplier | Assurance | Expiry | Status | Action |
|---|---|---|---|---|
| Supplier A | ISO 27001 | 30-Jun-2027 | Valid | Continue monitoring |
| Supplier B | SOC 2 Type II | 15-Aug-2026 | Expired | Request updated report |
| Supplier C | ISO 27001 | 20-Dec-2026 | Expiring | Initiate renewal review |
Where required evidence expires, the supplier owner should determine whether:
- Updated evidence should be requested
- Alternative assurance should be obtained
- A risk assessment should be performed
- A temporary exception is appropriate
- Supplier usage should be restricted
12. Vulnerability Monitoring
For technology suppliers, monitor information relevant to vulnerabilities affecting the services used by the organization.
Examples:
- Critical vulnerabilities
- Actively exploited vulnerabilities
- Security advisories
- Unsupported software
- Product security notices
- Emergency patches
- Vulnerabilities affecting customer environments
- Vulnerabilities affecting supplier-managed infrastructure
The organization should determine whether the vulnerability affects its actual use of the supplier.
A vulnerability announcement alone does not automatically mean that the organization has a high-risk exposure.
The assessment should consider:
Vulnerability → Affected Service → Organization’s Usage → Exposure → Controls → Business Impact → Risk
13. Incident Monitoring
Suppliers should be monitored for security incidents that may affect the organization.
Examples:
- Data breach
- Unauthorized access
- Malware incident
- Ransomware
- Cloud compromise
- Credential compromise
- Service disruption
- Supply-chain attack
- Data leakage
- Critical vulnerability exploitation
Where an incident is reported, the organization should determine:
- What happened?
- Which service was affected?
- Was organizational information involved?
- Was customer or personal data involved?
- Was organizational access involved?
- What systems were affected?
- What containment actions were taken?
- What is the expected business impact?
- Are contractual notifications required?
- Is supplier risk reassessment required?
Serious incidents should be handled under the organization’s Supply Chain Security Incident Response Procedure.
14. Subprocessor Monitoring
Where suppliers use subprocessors, monitor relevant changes.
Examples:
- New subprocessor
- Subprocessor replacement
- New processing location
- New data category
- Change in service
- Change in security responsibilities
The organization should determine whether the change affects:
- Privacy
- Information security
- Data location
- Contractual obligations
- Customer commitments
- Risk assessment
- DPA requirements
15. Data Location Monitoring
For suppliers handling sensitive or personal information, monitor relevant changes to:
- Hosting locations
- Processing locations
- Backup locations
- Data residency
- Cross-border transfers
- Subprocessor locations
A material change should trigger reassessment where required.
16. Availability and Performance Monitoring
For important suppliers, monitor service availability and performance.
Examples:
- SLA compliance
- Availability
- Response time
- Incident frequency
- Service degradation
- Support response
- Recovery performance
- Missed service commitments
For critical suppliers, monitoring should also consider:
- Recovery capability
- RTO/RPO requirements
- Disaster recovery testing
- Alternative arrangements
- Exit/migration capability
- Concentration risk
17. Material Change Monitoring
A supplier should be monitored for significant changes.
Examples include:
- Ownership change
- Merger or acquisition
- Major restructuring
- New service
- Major architecture change
- New subprocessor
- Data-location change
- Security incident
- Certification expiry
- Regulatory change
- Significant SLA deterioration
- Increased production access
- Increased data processing
- Service discontinuation
Material changes should trigger supplier risk reassessment when appropriate.
18. Periodic Supplier Review
In addition to ongoing monitoring, suppliers should undergo periodic formal review based on risk.
A review may include:
- Supplier profile
- Services
- Information handled
- Access
- Security controls
- Incidents
- Vulnerabilities
- Assurance
- Privacy
- Subprocessors
- Data locations
- Availability
- SLA performance
- BCP/DR
- Contract compliance
- Findings
- Risk changes
- Exit arrangements
The formal review should be documented in the Supplier Security Review Template.
19. Suggested Monitoring Frequency
The organization may establish a risk-based frequency such as:
| Supplier Risk | Example Monitoring |
|---|---|
| Low | Annual or as needed |
| Medium | Periodic monitoring and annual review |
| High | More frequent security/access/assurance monitoring and formal review |
| Critical | Enhanced ongoing monitoring and formal periodic review |
These frequencies are examples and should be adjusted according to organizational risk, contractual requirements, regulatory requirements, and business dependency.
20. Event-Driven Monitoring
A formal review should be initiated when significant events occur, regardless of the normal review schedule.
Triggers may include:
- Security incident
- Data breach
- Critical vulnerability
- Major service outage
- New subprocessor
- Data-location change
- Ownership change
- Increased production access
- New sensitive information
- Significant business dependency
- Assurance/certification expiry
- Major contract amendment
- Regulatory change
- Repeated SLA failures
- Supplier financial/operational concerns
- Planned supplier termination
21. Monitoring Findings
Issues identified during monitoring should be documented.
Example:
| Finding | Risk | Action | Owner | Due Date | Status |
|---|---|---|---|---|---|
| SOC 2 report expired | Medium | Request updated report | Supplier Owner | 15-Oct | Open |
| Former supplier user still active | High | Revoke access | IT | Immediate | Closed |
| New subprocessor identified | Medium | Privacy reassessment | Privacy Owner | 10-Oct | Open |
Findings should be tracked until:
- Corrected
- Verified
- Formally accepted
- Transferred to another risk treatment process
- Supplier relationship is restricted or terminated
22. Supplier Risk Reassessment
Monitoring results should be considered when reassessing supplier risk.
Reassessment may result in:
- No change in risk
- Reduced risk
- Increased risk
- New risk
- New controls
- Additional contractual requirements
- Additional monitoring
- Risk treatment
- Risk acceptance
- Supplier restriction
- Supplier offboarding
The updated risk should be recorded in the relevant supplier risk assessment or risk register.
23. Escalation
Issues should be escalated according to their potential impact.
Examples:
Operational Issue
Repeated SLA failure.
→ Supplier owner manages corrective action.
Security Issue
Significant vulnerability affecting a supplier service.
→ Security team assesses exposure and risk.
Major Security Incident
Supplier reports compromise involving organizational information.
→ Incident response process is initiated.
Critical Supplier Failure
Critical cloud or infrastructure provider suffers prolonged outage.
→ Business continuity and recovery processes may be activated.
24. Supplier Monitoring Register
A monitoring register may be maintained with fields such as:
| Field | Example |
|---|---|
| Monitoring ID | MON-001 |
| Supplier ID | SUP-001 |
| Supplier | Cloud Provider |
| Criticality | Critical |
| Monitoring Area | Security |
| Monitoring Date | 15-Sep-2026 |
| Evidence | SOC 2 report |
| Finding | No significant issue identified |
| Risk Change | No change |
| Action | Continue monitoring |
| Owner | Security Manager |
| Next Review | 15-Dec-2026 |
| Status | Completed |
25. AWS SaaS Example
Consider a startup operating a SaaS application on AWS.
Key suppliers include:
- AWS – infrastructure
- GitHub – source-code repository
- Auth0 – identity/authentication
- Stripe – payment processing
- Datadog – monitoring
- Customer-support SaaS – support operations
The organization may monitor:
AWS
- Service availability
- Security incidents
- Assurance reports
- Production dependency
- IAM/security requirements
- Data-location requirements
- Backup/recovery
- Critical service changes
GitHub
- Security incidents
- Repository access
- MFA
- Organization membership
- Security advisories
- Critical dependency vulnerabilities
Auth0
- Authentication availability
- Security incidents
- MFA configuration
- Assurance evidence
- Subprocessors
- Data location
Stripe
- Payment-service availability
- Security/compliance assurance
- Incidents
- Contractual requirements
- Data-processing requirements
The monitoring depth should reflect each supplier’s actual role and risk.
26. Startup-Friendly Monitoring Model
A startup does not need a large supplier-management department to establish effective monitoring.
A practical model is:
Low-risk suppliers
Monitor:
- Contract status
- Service status
- Major changes
- Significant incidents
Medium-risk suppliers
Add:
- Security assurance
- Access
- Privacy
- Availability
- Periodic review
High-risk suppliers
Add:
- Security evidence
- Vulnerability information
- Incident monitoring
- Subprocessor changes
- Data-location monitoring
- Access review
- Formal risk reassessment
Critical suppliers
Add:
- Enhanced security monitoring
- Availability and recovery
- Concentration risk
- Exit/migration capability
- Business continuity
- Subprocessor monitoring
- Material technology changes
- More frequent formal review
This allows a small security team to focus effort where supplier risk is greatest.
27. Roles and Responsibilities
Supplier Owner
- Monitor supplier performance
- Coordinate reviews
- Maintain supplier records
- Track actions
Information Security
- Monitor security risks
- Review security evidence
- Assess incidents and vulnerabilities
- Review supplier access risks
IT/Engineering
- Review technical access
- Validate technical controls
- Monitor integrations and dependencies
Privacy/Legal
Where applicable:
- Review privacy requirements
- Review subprocessors
- Assess data-location changes
- Review contractual requirements
Business Owner
- Confirm business dependency
- Review service performance
- Confirm continued business need
Risk Owner
- Review significant supplier risks
- Approve or escalate risk treatment
28. Records and Evidence
The organization should retain appropriate evidence of supplier monitoring.
Examples:
- Monitoring records
- Supplier review reports
- Security questionnaires
- Assurance reports
- Certifications
- SLA reports
- Incident notifications
- Vulnerability notifications
- Access-review evidence
- Subprocessor notifications
- Data-location assessments
- Risk reassessments
- Corrective-action records
- Approval records
- Supplier communications
- Offboarding records
Evidence should be retained according to the organization’s information-retention requirements.
29. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Supplier Register | Identifies suppliers |
| Critical Supplier Register | Identifies critical suppliers |
| Supplier Risk Assessment | Determines supplier risk |
| Supplier Security Requirements | Defines required controls |
| Supplier Security Agreement | Establishes contractual obligations |
| Supplier Onboarding Checklist | Controls supplier onboarding |
| Supplier Monitoring Policy | Defines monitoring principles |
| Supplier Monitoring Procedure | Defines how monitoring is performed |
| Supplier Security Review | Performs formal supplier review |
| Supplier Risk Reassessment | Updates supplier risk |
| Supply Chain Incident Response | Handles supplier security incidents |
| Supplier Offboarding Checklist | Controls secure termination |
| Risk Register | Tracks significant organizational risks |
30. Common Mistakes
Mistake 1: Monitoring only during onboarding
Supplier risk can change after onboarding.
Better: Monitor throughout the relationship.
Mistake 2: Treating every supplier identically
A stationery supplier and cloud infrastructure provider do not create the same risk.
Better: Use risk-based monitoring.
Mistake 3: Only checking certifications
Certification provides useful assurance but does not answer every organization-specific risk question.
Better: Review actual service, information, access, dependency, incidents, and contractual requirements.
Mistake 4: Ignoring supplier access
Supplier access can remain active after the original business need changes.
Better: Periodically review supplier accounts, permissions, MFA, privileged access, and production access.
Mistake 5: Ignoring subprocessors
A supplier may rely on additional external providers.
Better: Monitor relevant subprocessor changes.
Mistake 6: Not recording evidence
Performing a review without retaining evidence makes it difficult to demonstrate the control operated.
Better: Maintain monitoring records and supporting evidence.
Mistake 7: No event-driven review
Waiting for the annual review after a major breach or critical change can leave risk unmanaged.
Better: Define event-driven monitoring triggers.
31. ISO 27001 Connection
Supplier monitoring supports the organization’s information-security risk-management and supplier-management processes.
The procedure should be linked to the organization’s:
- Risk assessment
- Risk treatment
- Statement of Applicability
- Supplier-management controls
- Information-security policies
- Incident-management process
- Business continuity process
- Access-control process
- Vulnerability-management process
- Internal audit process
The exact monitoring activities should be determined based on the organization’s risks, applicable requirements, supplier relationships, and ISMS scope.
A standalone Supplier Monitoring Procedure is an organizational implementation document; ISO/IEC 27001 does not require every organization to use this exact document or format.
32. Internal Audit Checklist
An auditor may verify:
- Supplier monitoring requirements are defined
- Suppliers are appropriately classified
- Monitoring frequency is risk-based
- Critical suppliers receive enhanced monitoring
- Supplier security evidence is reviewed
- Certifications/assurance reports are tracked
- Supplier access is periodically reviewed
- Supplier incidents are monitored
- Vulnerability information is considered
- Subprocessor changes are monitored
- Data-location changes are considered
- Availability/SLA performance is monitored where relevant
- Material changes trigger reassessment
- Findings are documented
- Corrective actions are tracked
- Significant risks are escalated
- Monitoring evidence is retained
- Supplier reviews are completed as planned
- Critical suppliers are reviewed appropriately
- Offboarding is initiated when required
33. Final Audit Trail
A strong supplier-monitoring audit trail should demonstrate:
Supplier Identified
↓
Supplier Classified
↓
Risk Assessed
↓
Monitoring Requirements Defined
↓
Monitoring Performed
↓
Evidence Collected
↓
Changes/Issues Identified
↓
Risk Impact Assessed
↓
Corrective Action / Risk Treatment
↓
Risk Reassessment
↓
Approval / Escalation
↓
Continued Monitoring or Offboarding
Final Principle
Supplier monitoring is not simply asking a supplier once a year, “Are you still secure?”
Effective monitoring demonstrates that the organization understands:
Who the supplier is → What service they provide → What information and systems are involved → What access they have → How critical the dependency is → What has changed → What evidence exists → What risks remain → What actions are required.
The objective is to maintain visibility and control over supplier risk throughout the entire supplier lifecycle—not just at onboarding or contract signing.