ISO 27001 Supplier Management: Third-Party Risk Requirements

Your ISMS is only as strong as your weakest supplier. Every SaaS company depends on a web of third-party relationships — cloud infrastructure providers hosting your production environment, identity providers managing authentication, payment processors handling financial data, monitoring tools ingesting your telemetry, and dozens of other services that your application relies on to function. ISO 27001 recognizes this reality and requires that you systematically identify, evaluate, and manage the information security risks introduced by these relationships.

This is not a theoretical concern. When a supplier suffers a breach, their failure becomes your exposure. Customer data processed by a compromised sub-processor is still your responsibility. An identity provider outage that locks your users out of your platform is still your availability failure. A dependency with a backdoor injected into your build pipeline is still your security incident. ISO 27001 Annex A controls A.5.19 through A.5.23 exist precisely because supplier relationships are one of the most significant and persistent sources of information security risk.

This guide covers the ISO 27001 requirements for supplier management, explains each relevant Annex A control, walks through the practical processes for due diligence, contractual alignment, and ongoing monitoring, and addresses the specific supply chain challenges that SaaS companies face.

ISO 27001 Supplier Management Controls Explained

The 2022 revision of ISO 27001 groups supplier management controls under section A.5, within the organizational controls category. Five controls create a comprehensive framework for managing third-party risk.

A.5.19 — Information Security in Supplier Relationships

This is the foundational control. It requires you to establish and document a policy and procedures for managing information security risks associated with the use of supplier products and services. The policy must address:

• The types of suppliers and the types of access they have to your information and systems
• The minimum information security requirements for each type of supplier relationship
• Processes for assessing supplier information security capabilities before entering into a relationship
• The criteria for selecting and approving suppliers
• Responsibilities for managing supplier relationships throughout their lifecycle

This control establishes that supplier management is not ad hoc — it is a defined, repeatable process governed by documented policy. Your supplier information security policy should be part of your broader ISMS policy framework.

A.5.20 — Addressing Information Security Within Supplier Agreements

Once you have selected a supplier, this control requires that you establish and agree upon relevant information security requirements with each supplier that may access, process, store, communicate, or provide IT infrastructure components for your information. In practical terms, this means your contracts must include:

• Clear definition of the information and services the supplier will access or provide
• Information security requirements specific to the relationship (encryption standards, access controls, audit rights)
• Incident notification obligations (how quickly the supplier must inform you of security incidents affecting your data)
• The supplier’s obligation to comply with your information security requirements or equivalent standards
• Your right to audit the supplier’s compliance with agreed requirements
• Requirements for the supplier’s management of their own sub-suppliers (your fourth-party risk)
• Return or destruction of your information upon termination of the relationship
• Confidentiality and non-disclosure obligations

These requirements are typically implemented through a combination of the master service agreement, a data processing agreement (see our GDPR DPA guide for requirements when personal data is involved), and information security schedules or addenda.

A.5.21 — Managing Information Security in the ICT Supply Chain

This control specifically addresses the supply chain risks in information and communication technology (ICT) products and services. For SaaS companies, this is directly relevant because your software supply chain includes open-source libraries, commercial components, cloud services, and SaaS-to-SaaS integrations.

The control requires you to:

• Define and implement processes for managing ICT supply chain security risks
• Require that suppliers propagate appropriate security practices throughout the supply chain
• Include ICT supply chain risks in your risk assessment process
• Monitor for supply chain threats (compromised dependencies, malicious updates, vendor breaches)

In the SaaS context, this control drives practices like software composition analysis, dependency vulnerability scanning, vendor security questionnaire programs, and sub-processor monitoring.

A.5.22 — Monitoring, Review and Change Management of Supplier Services

Supplier management is not a one-time activity. This control requires ongoing monitoring and periodic review of supplier services and any changes to supplier service delivery. Specifically, you must:

• Monitor supplier service performance and security on an ongoing basis
• Review supplier compliance with agreed information security requirements
• Manage changes to supplier services (including changes to the supplier’s sub-suppliers, technology platforms, or security posture)
• Evaluate whether changes in the supplier’s service affect your information security risk profile

For SaaS companies, this translates to regular review of supplier SOC 2 reports, monitoring vendor security advisories, tracking changes to supplier sub-processor lists, and reassessing vendor risk when significant changes occur.

A.5.23 — Information Security for Use of Cloud Services

This is a new control introduced in the 2022 revision, reflecting the central role of cloud services in modern information systems. It requires you to establish processes for the acquisition, use, management, and exit from cloud services, with specific attention to:

• Defining information security requirements for cloud services based on your security needs
• Establishing cloud service selection criteria that include security capabilities
• Defining roles and responsibilities between your organization and the cloud service provider (the shared responsibility model)
• Managing the security controls that are your responsibility under the shared responsibility model
• Establishing exit strategies for cloud services, including data retrieval and deletion verification

This control acknowledges that cloud services present unique supplier management challenges — you are sharing responsibility for security with the provider, and the boundary of that shared responsibility varies by service model (IaaS, PaaS, SaaS).

For a complete mapping of all Annex A controls, see our ISO 27001 Annex A controls guide.

Supplier Classification and Tiering

Not every supplier carries the same risk. A cloud infrastructure provider hosting your production database is fundamentally different from a design tool used by your marketing team. ISO 27001 requires that your supplier management effort be proportional to the risk each supplier introduces. Classification and tiering make this practical.

Building a Supplier Inventory

Before you can classify suppliers, you need a complete inventory. This is harder than it sounds because SaaS companies typically adopt tools rapidly and sometimes without centralized procurement oversight.

Discovery methods:

• Financial records — Invoices, credit card statements, and subscription management platforms reveal every tool and service the organization pays for. This is the most reliable source.
• SSO and identity provider logs — Your identity provider (Okta, Google Workspace, Azure AD) shows which SaaS applications employees access. Applications not integrated with SSO are a gap worth investigating.
• Network traffic analysis — DNS and proxy logs reveal external services your systems communicate with, including those that may not be formally procured.
• Department surveys — Ask each team what tools and services they use. This catches free-tier tools and shadow IT that do not appear in financial records.
• Engineering architecture review — Review your infrastructure diagrams, dependency manifests (package.json, requirements.txt, Gemfile), and deployment configurations to identify all external services your application depends on.

Tiering Framework

Assign each supplier to a tier based on the risk they introduce. A three-tier model balances rigor with practicality:

Tier	Criteria	Due Diligence Level	Review Frequency	Examples
Tier 1 — Critical	Processes or stores customer data, hosts production infrastructure, provides security-critical services, or would cause significant business disruption if unavailable	Full due diligence: security questionnaire, SOC 2/ISO 27001 report review, penetration test results, contractual security requirements	Annually (minimum), plus event-triggered reviews	AWS/GCP/Azure, primary database provider, identity provider, payment processor
Tier 2 — Significant	Accesses internal sensitive data, integrates with production systems, or provides important business services	Standard due diligence: security questionnaire, certification review, contractual security requirements	Annually	CI/CD platforms, monitoring tools, communication platforms with data integrations, HR systems
Tier 3 — Low	No access to sensitive data, no integration with production systems, limited business impact	Basic due diligence: certification status check, privacy policy review	Every 2 years	Design tools, project management (without sensitive data), office supplies, marketing analytics

Classification factors to evaluate:

• Data access: What types of data does the supplier access? Customer data, employee data, financial data, intellectual property?
• Data processing: Does the supplier store your data, process it, or merely transit it?
• System integration: Is the supplier integrated with your production environment? Can a compromise of the supplier reach your systems?
• Business criticality: What happens if this supplier becomes unavailable? Minutes of downtime or inconvenience?
• Regulatory exposure: Does the supplier’s access to personal data create obligations under GDPR or other privacy regulations?
• Replaceability: How quickly could you switch to an alternative? High switching costs increase the risk of vendor lock-in.

Supplier Due Diligence Process

Due diligence is the process of evaluating a supplier’s information security posture before entering into a relationship and periodically thereafter. The depth of due diligence should be proportional to the supplier’s tier classification.

Pre-Engagement Assessment

Step 1: Gather supplier security documentation.

Request the following based on supplier tier:

For Tier 1 suppliers:

• ISO 27001 certificate (check the scope covers the services you will use, verify the certificate with the certification body)
• SOC 2 Type II report (read the full report, not just the opinion — check for exceptions, qualified opinions, and complementary user entity controls)
• Penetration test summary or executive report (look for critical and high findings and whether they were remediated)
• Completed security questionnaire (SIG, CAIQ, or your custom questionnaire)
• Business continuity and disaster recovery documentation
• Privacy and data processing documentation (DPA, sub-processor list, data flow diagrams)
• Insurance certificates (cyber liability, professional indemnity)

For Tier 2 suppliers:

• ISO 27001 certificate or SOC 2 report
• Completed security questionnaire (abbreviated version acceptable)
• Privacy policy and data processing terms
• Incident notification procedures

For Tier 3 suppliers:

• Public security page or trust center review
• Privacy policy review
• Basic questionnaire (5-10 questions covering encryption, access control, incident response)

Step 2: Evaluate the documentation.

Do not just check boxes. Analyze the documentation critically:

• SOC 2 report scope: Does the report scope cover the specific services you are using? A company may have a SOC 2 report for one product but not for the product you are purchasing.
• Exceptions and qualifications: SOC 2 reports may contain exceptions — instances where a control did not operate effectively. Read them carefully and assess whether they affect your risk.
• ISO 27001 certificate validity: Check the certificate expiry date and verify it with the issuing certification body. Some organizations continue presenting expired certificates.
• Penetration test findings: Focus on findings relevant to the services you use. Critical or high findings that remain open are significant risk indicators.
• Sub-processor list: Identify the supplier’s own third parties that may access your data. Your fourth-party risk is part of your third-party risk.

Step 3: Assess residual risk.

After reviewing documentation, determine whether any residual risks require additional controls, risk acceptance, or are deal-breakers. Document your risk assessment for each Tier 1 and Tier 2 supplier and incorporate it into your overall risk assessment.

Security Questionnaire Design

If you use a custom security questionnaire (rather than or in addition to standard frameworks like SIG or CAIQ), focus on questions that produce actionable answers:

Identity and access management:

• How does the supplier control access to your data? What authentication mechanisms are used?
• Does the supplier enforce MFA for all access to systems that process your data?
• How are access rights reviewed and revoked for terminated employees?

Data protection:

• How is your data encrypted at rest and in transit? What encryption standards and key lengths are used?
• Where is your data stored geographically? Does the supplier use sub-processors in jurisdictions outside your approved list?
• What is the supplier’s data retention policy? How is your data deleted upon contract termination?

Incident management:

• What is the supplier’s incident notification timeframe? (Look for specific commitments — “promptly” is not a timeframe)
• Does the supplier conduct post-incident reviews and share relevant findings with affected customers?
• Has the supplier experienced any security incidents in the past 24 months?

Business continuity:

• What are the supplier’s recovery time and recovery point objectives?
• Does the supplier test their disaster recovery procedures? How often?
• What is the supplier’s uptime track record and SLA?

Security program maturity:

• Does the supplier hold ISO 27001 certification or SOC 2 attestation?
• Does the supplier conduct regular penetration testing? By whom?
• Does the supplier have a vulnerability disclosure program?

Contractual Security Requirements

Control A.5.20 requires that information security requirements are formally agreed in supplier contracts. These requirements protect your organization legally and operationally when supplier relationships do not go as planned.

Essential Contract Clauses

Data processing terms. Define exactly what data the supplier will access, how they may process it, where they may store it, and for how long. If personal data is involved, a formal Data Processing Agreement is required under GDPR (see our GDPR DPA guide).

Security requirements. Specify the minimum security controls the supplier must maintain:

• Encryption standards (TLS 1.2+ in transit, AES-256 at rest)
• Access control requirements (MFA, role-based access, privileged access management)
• Logging and monitoring obligations
• Vulnerability management expectations (patching SLAs, penetration testing frequency)
• Employee background check requirements for personnel with access to your data

Incident notification. Require the supplier to notify you of security incidents affecting your data within a defined timeframe. For suppliers processing personal data subject to GDPR, this must be fast enough to allow you to meet your own 72-hour notification obligation. A common standard is requiring notification within 24-48 hours. Include requirements for the content of the notification: what happened, what data was affected, what the supplier is doing about it, and the contact information for their incident team.

Audit rights. Reserve the right to audit the supplier’s compliance with agreed security requirements, either directly or through an independent third party. For Tier 1 suppliers, this clause is non-negotiable. In practice, most SaaS companies exercise audit rights through SOC 2 report reviews rather than on-site audits, but having the contractual right enables you to conduct a direct audit if the SOC 2 report raises concerns.

Sub-processor management. Require the supplier to notify you before engaging new sub-processors that will access your data. Define your right to object to sub-processor changes. This is particularly important under GDPR, where you need to maintain an accurate picture of all entities processing personal data on your behalf.

Data return and destruction. Upon contract termination, the supplier must return all your data in a usable format and certify that all copies have been securely destroyed. Define the timeframe for return and destruction (30 days is common) and the method of destruction certification (written attestation from an authorized officer, certificate of destruction).

Compliance obligations. Require the supplier to maintain relevant certifications (ISO 27001, SOC 2) throughout the term of the agreement and to notify you if their certification lapses or if they receive qualified audit opinions.

Liability and indemnification. Define the supplier’s liability in the event of a security breach caused by their failure to meet agreed security requirements. Include indemnification for regulatory fines, notification costs, and customer claims resulting from supplier breaches.

Cloud Provider Assessment and the Shared Responsibility Model

Control A.5.23 specifically addresses cloud services, recognizing that cloud provider relationships are fundamentally different from traditional supplier relationships because of the shared responsibility model.

Understanding Shared Responsibility

In a cloud environment, security is divided between the cloud provider and the customer. The exact division depends on the service model:

Infrastructure as a Service (IaaS) — AWS EC2, GCP Compute Engine, Azure VMs:

• Provider responsibility: Physical security, hypervisor, network infrastructure, storage infrastructure
• Your responsibility: Operating system patching, application security, data encryption, access management, network configuration, logging, monitoring

Platform as a Service (PaaS) — AWS RDS, Google App Engine, Azure App Service:

• Provider responsibility: Everything in IaaS plus operating system, runtime environment, and middleware
• Your responsibility: Application code, data, access management, application-level encryption, monitoring

Software as a Service (SaaS) — Salesforce, Slack, Datadog:

• Provider responsibility: Nearly everything — infrastructure, platform, application, physical security
• Your responsibility: Data classification, access management (user provisioning/deprovisioning, MFA enforcement), configuration settings, integration security

Assessing Cloud Providers

For IaaS and PaaS providers (your Tier 1 suppliers), assessment focuses on:

Certifications and attestations. Major cloud providers maintain comprehensive certification portfolios. Verify that the specific services and regions you use are within the scope of their certifications. AWS’s ISO 27001 certificate, for example, covers specific services listed in the scope — verify that your services are included.

Shared responsibility documentation. Review the provider’s shared responsibility model documentation to understand exactly what they secure and what you must secure. Map this against your control requirements to ensure no gaps exist.

Complementary User Entity Controls (CUECs) / Complementary Subservice Organization Controls (CSOCs). Cloud provider SOC 2 reports list controls they expect you to implement on your end. If you rely on AWS but have not implemented their CUECs around encryption key management, network security, and access controls, there is a gap in your control environment that your auditor will identify.

Data residency and sovereignty. Verify that the provider can meet your data residency requirements. If you have committed to storing EU customer data in the EU, confirm that the specific cloud regions and services you use comply. Account for data replication, backup storage locations, and support access that may cross geographic boundaries.

Exit strategy. Control A.5.23 requires exit planning. Assess the feasibility of migrating away from the cloud provider: data export formats, API compatibility, contractual terms for data retrieval, and the timeline for data deletion post-termination. Vendor lock-in is a risk that must be managed.

Ongoing Monitoring and Review

Control A.5.22 requires ongoing monitoring — supplier management does not end after the contract is signed. Your monitoring program must track supplier security posture, service performance, and changes that affect your risk profile.

Continuous Monitoring Activities

Certification and report tracking. Track the expiry dates for every supplier’s ISO 27001 certificate and SOC 2 report observation period. Request updated reports before they expire. A supplier whose SOC 2 report expired six months ago and who has not produced a new one is a risk indicator that requires investigation.

Security advisory monitoring. Monitor supplier security advisories, breach notifications, and vulnerability disclosures. Many suppliers publish security advisories through email lists, status pages, or trust portals. Subscribe to these channels for all Tier 1 and Tier 2 suppliers.

Sub-processor change notifications. Track changes to supplier sub-processor lists. Under GDPR, processors must inform you of new sub-processors before engaging them. Under ISO 27001, changes to sub-processors may affect your risk profile and require reassessment.

Performance and availability tracking. Monitor supplier uptime, response times, and SLA compliance. Persistent performance degradation may indicate underlying security or operational issues.

News and threat intelligence. Monitor security news sources and threat intelligence feeds for reports of breaches, vulnerabilities, or other security events affecting your suppliers. You may become aware of a supplier compromise through public reporting before the supplier formally notifies you.

Periodic Review Process

Annual supplier review (Tier 1). Conduct a comprehensive annual review of each Tier 1 supplier:

• Request and review updated SOC 2 Type II report or ISO 27001 surveillance audit results
• Review any security incidents the supplier reported during the year
• Reassess the supplier’s risk classification based on any changes in the relationship
• Review contractual terms for adequacy (security requirements, notification timeframes, audit rights)
• Verify that your complementary controls are still effective
• Update your risk register with any changes to supplier-related risks

Annual supplier review (Tier 2). Conduct a lighter review of Tier 2 suppliers:

• Verify certification status
• Review any reported incidents
• Confirm data processing activities have not changed materially
• Update risk classification if needed

Biennial supplier review (Tier 3). Review Tier 3 suppliers every two years:

• Verify the supplier is still appropriate for the service provided
• Check for any significant security events
• Confirm the relationship has not expanded in scope (which might warrant reclassification)

Handling Supplier Risk Changes

When monitoring reveals a change in supplier risk, you need a defined response process:

Supplier reports a security incident. Activate your own incident management procedures. Assess whether your data was affected. Determine whether the supplier incident triggers your own notification obligations. Request a post-incident report from the supplier and evaluate whether your risk assessment and controls need updating.

Supplier certification lapses. A lapsed ISO 27001 certificate or an overdue SOC 2 report is a significant risk indicator. Contact the supplier to understand why. Request alternative evidence of their security posture (recent penetration test, security questionnaire update). Escalate internally and consider whether compensating controls are needed while the certification gap persists.

Supplier sub-processor change. Evaluate the new sub-processor against your security requirements. Assess whether the change introduces new risks (new jurisdiction, new data access, different security posture). Exercise your right to object if the change is unacceptable.

Supplier acquisition or material business change. When a supplier is acquired, their security posture may change. Reassess the relationship, review updated terms and certifications, and determine whether the acquiring entity meets your requirements.

Supplier Incident Handling

When a supplier experiences a security incident that may affect your organization, your response must be coordinated with the supplier’s response.

Supplier incident notification receipt. When you receive an incident notification from a supplier:

1. Log the notification with timestamp, source, and content
2. Assess the potential impact on your data and systems
3. Determine whether your own incident response procedures should be activated
4. Identify whether the supplier incident triggers your notification obligations to customers or regulators
5. Request regular updates from the supplier on investigation progress and remediation

Your responsibilities during a supplier incident:

• Implement any recommended mitigations (credential rotation, access restriction, enhanced monitoring)
• Assess the blast radius within your own environment
• Preserve relevant logs and evidence from your systems that may aid investigation
• Coordinate customer communications if customer data may be affected
• Track the supplier’s remediation progress and verify that vulnerabilities are addressed

Post-supplier-incident review. After the supplier incident is resolved:

• Request a detailed post-incident report from the supplier
• Evaluate whether the supplier’s response was adequate
• Reassess the supplier’s risk classification
• Determine whether contractual changes are needed (stricter notification requirements, additional security obligations)
• Update your risk register and controls based on lessons learned

Supplier Offboarding and Data Return/Destruction

The end of a supplier relationship is a high-risk period that many organizations handle poorly. ISO 27001 requires that you manage supplier exits with the same rigor as supplier onboarding.

Offboarding Process

Step 1: Data inventory and return. Before terminating the relationship:

• Identify all data held by the supplier (production data, backups, logs, test data)
• Request export of all data in a usable, portable format
• Verify the completeness of the returned data
• Transfer data to your systems or a replacement supplier

Step 2: Access revocation. Immediately upon termination:

• Revoke the supplier’s access to your systems (API keys, service accounts, VPN access, SSH keys)
• Revoke your team’s access to the supplier’s systems (to prevent accidental continued use)
• Remove the supplier from your SSO/identity provider integrations
• Update firewall rules and network configurations to block supplier connectivity

Step 3: Data destruction verification.

• Request written certification from the supplier that all copies of your data have been securely destroyed
• The certification should specify the destruction method, date, and the data sets destroyed
• For suppliers processing personal data under GDPR, data destruction verification is a legal requirement
• Set a follow-up reminder to confirm destruction within the contractually agreed timeframe (typically 30-90 days)

Step 4: Documentation update.

• Update your supplier inventory to reflect the terminated relationship
• Update your risk register to remove or modify supplier-related risks
• Archive the supplier’s security documentation, contract, and correspondence for your records
• If the supplier was a sub-processor listed in your customer-facing data processing documentation, update those records

SaaS Supply Chain Considerations

SaaS companies face supply chain risks that are distinct from traditional enterprise supplier management. Your ISO 27001 program must account for these.

Open-Source Dependency Risk

Your application likely depends on hundreds or thousands of open-source libraries. Each one is part of your supply chain, and each one carries risk.

Software composition analysis (SCA). Implement automated scanning of your dependency manifests to identify known vulnerabilities, license compliance issues, and outdated packages. SCA should be integrated into your CI/CD pipeline so vulnerable dependencies are caught before deployment.

Dependency pinning and integrity verification. Pin dependency versions and verify package integrity using checksums or signatures. This prevents attacks where a malicious actor publishes a compromised version of a popular package.

Monitoring for supply chain attacks. Subscribe to security advisories for your critical dependencies. Monitor for reports of compromised packages, typosquatting attacks, and maintainer account compromises.

SaaS-to-SaaS Integrations

Modern SaaS architectures often involve extensive integrations between SaaS services. Each integration creates a data flow that must be evaluated as a supplier relationship.

OAuth token management. SaaS integrations typically use OAuth tokens for authentication. These tokens grant access to your data and must be managed as credentials: inventoried, minimally scoped, regularly reviewed, and revoked when no longer needed.

Data flow mapping. For each SaaS-to-SaaS integration, document what data flows between the services, in which direction, for what purpose, and what the receiving service does with it. This mapping supports both your ISO 27001 compliance and your GDPR data processing records.

Integration access reviews. Periodically review all active SaaS integrations. Identify integrations that are no longer needed, integrations with excessive permissions, and integrations connected by former employees whose accounts have been deprovisioned but whose integrations persist.

API Security in Supplier Relationships

APIs are the connective tissue of SaaS supply chains. Supplier APIs introduce risks that must be managed:

API authentication and authorization. Ensure that supplier API integrations use strong authentication (API keys, OAuth, mutual TLS). Review the supplier’s API security documentation for rate limiting, input validation, and access control practices.

API versioning and deprecation. Monitor supplier API version announcements. Deprecated APIs may receive reduced security attention. Plan migrations to supported API versions within the supplier’s deprecation timeline.

Data minimization in API calls. Request only the data you need from supplier APIs. Overly broad API queries retrieve and transmit data unnecessarily, increasing the impact of a potential interception or supplier breach.

Building an ISO 27001-Compliant Supplier Management Program: Step by Step

For SaaS companies building their supplier management program as part of ISO 27001 implementation, here is a practical roadmap:

Month 1: Foundation

• Draft and approve your supplier information security policy (A.5.19)
• Define your supplier tiering framework
• Begin the supplier inventory by analyzing financial records and SSO logs

Month 2: Inventory and Classification

• Complete the supplier inventory across all departments
• Classify each supplier into the appropriate tier
• Prioritize Tier 1 suppliers for immediate due diligence

Month 3-4: Tier 1 Due Diligence

• Request security documentation from all Tier 1 suppliers
• Evaluate SOC 2 reports, ISO 27001 certificates, and questionnaire responses
• Identify contractual gaps and initiate renegotiation for missing security clauses
• Document risk assessments for each Tier 1 supplier

Month 5: Tier 2 Due Diligence and Contractual Alignment

• Complete Tier 2 supplier assessments
• Ensure all Tier 1 and Tier 2 contracts include required security clauses (A.5.20)
• Execute DPAs where personal data processing requires them

Month 6: Monitoring Program Launch

• Establish certification and report tracking for all Tier 1 and Tier 2 suppliers
• Subscribe to security advisory channels for critical suppliers
• Set up calendar reminders for annual review cycles
• Document your monitoring procedures

Ongoing: Operate and Improve

• Conduct annual supplier reviews according to your tiering schedule
• Process supplier incident notifications through your incident management procedures
• Manage supplier onboarding and offboarding using your defined processes
• Report supplier risk status in management reviews
• Update your supplier management program based on lessons learned and audit findings

This program should align with your overall ISO 27001 certification checklist and connect to your risk assessment and continuous improvement processes.

Common Mistakes in ISO 27001 Supplier Management

No supplier inventory. You cannot manage what you have not identified. Organizations that skip the inventory step and manage only the suppliers they happen to think of will have gaps. Shadow IT — tools adopted by individual teams without centralized procurement — is the most common source of unmanaged supplier risk.

Treating all suppliers the same. Applying the same due diligence rigor to your office supplies vendor as to your cloud infrastructure provider wastes resources on low-risk suppliers while potentially under-investing in critical ones. Tiering makes your program proportional and sustainable.

Accepting self-attestation as due diligence. A supplier telling you they are secure is not evidence that they are secure. Require independent evidence: ISO 27001 certificates issued by accredited certification bodies, SOC 2 reports from qualified audit firms, penetration test reports from reputable testers. Self-completed security questionnaires supplement but do not replace independent attestation.

Contracts without security clauses. If your contract with a critical supplier does not include security requirements, incident notification obligations, and audit rights, you have no contractual basis for holding them accountable when something goes wrong. Retrofitting security clauses into existing contracts is difficult — include them from the start.

One-time due diligence with no ongoing monitoring. A supplier that passed your assessment two years ago may not meet your requirements today. People change, architectures change, ownership changes. Ongoing monitoring (A.5.22) is not optional — it is a separate, explicit control requirement.

Ignoring the shared responsibility model. SaaS companies that assume their cloud provider handles all security are creating critical gaps. Your cloud provider secures their infrastructure. You must secure your configuration, your access management, your data, and your applications. Failure to implement your complementary controls is a finding in your ISO 27001 audit and a real security vulnerability.

No offboarding process. Suppliers with lingering access after contract termination are a security risk. Data that is not confirmed destroyed after a relationship ends is a compliance risk. Define and execute an offboarding process for every supplier relationship that ends.

Not monitoring SaaS-to-SaaS integrations. OAuth tokens and API integrations created between SaaS services are supplier relationships that many organizations fail to inventory and manage. An unused integration with broad permissions is an attack surface waiting to be exploited.

How GRCTrail Helps

GRCTrail provides SaaS companies with a structured supplier management program that satisfies ISO 27001 Annex A controls A.5.19-A.5.23 while making ongoing vendor oversight manageable at scale.

• Centralized supplier registry with tiering that inventories every vendor, classifies them by risk level, tracks their security documentation (ISO 27001 certificates, SOC 2 reports, questionnaire responses), and alerts you when certifications or reports approach expiration
• Due diligence workflow automation that guides your team through the assessment process for each supplier tier, tracks document collection, and records risk assessment decisions in an auditable format your certification body can review
• Ongoing monitoring dashboards with automated reminders for annual reviews, sub-processor change tracking, and integration with your risk register so supplier risk changes flow directly into your ISMS management review

Get started with GRCTrail →

Related Guides

• What Is ISO 27001? A Complete Guide for SaaS Companies
• ISO 27001 Risk Assessment: Framework and Process
• ISO 27001 Annex A Controls: Complete Guide
• ISO 27001 Certification Checklist
• SOC 2 Vendor Management: Third-Party Risk Requirements
• GDPR Data Processing Agreements: A Complete Guide
• ISO 27001 Policies: What You Need to Document