Annex A Controls

A.5.19 through A.5.22 — Supplier Security Management

Alex Fuerst

15 Sep 2025 — 7 min read

The Foundation Crisis: Understanding A.5.19 Information Security in Supplier Relationships

The audit still haunts me. A mid-sized fintech with pristine internal controls—hardened infrastructure, quarterly penetration tests, mandatory security awareness training. Then I asked for their supplier inventory. The IT director sheepishly produced a spreadsheet from 2022 listing four vendors. Their accounts payable system showed active relationships with forty-seven technology providers. That 43-vendor gap? That's where the next SolarWinds happens.

Control 5.19 (formerly A.15.1.1) requires organizations to define and implement processes for managing information security risks in supplier relationships. This isn't about having a process—it's about having the right process, applied consistently, before you need it. Most organizations I audit treat supplier security as a procurement afterthought rather than a foundational security architecture decision.

The control's guidance in ISO/IEC 27002:2022 is comprehensive, covering thirteen specific areas from supplier identification to secure termination procedures. Here's what actually works in practice: establish supplier tiers based on data access and business criticality. Tier 1 might include cloud infrastructure providers and payment processors—suppliers with direct access to production systems or customer data. Tier 2 covers suppliers with network access or significant business information. Tier 3 includes limited-access vendors like cleaning services or office suppliers.

Each tier needs proportionate security requirements. For Tier 1 suppliers, you need documented security controls equivalent to what you'd require internally, evidence of security certifications (ISO 27001, SOC 2), incident notification procedures, and right-to-audit clauses. Tier 2 might require basic security questionnaires and annual attestations. Tier 3 could rely on contract language and periodic reviews.

The key implementation mistake I see: organizations try to apply the same security requirements to all suppliers. This creates vendor fatigue, procurement delays, and ultimately circumvention of the entire process. Your office cleaning contractor doesn't need a SOC 2 report, but your cloud hosting provider absolutely does.

Making Agreements Enforceable: Control 5.20 in Practice

Control 5.20 (formerly A.15.1.2) addresses information security within supplier agreements, and this is where legal, procurement, and security teams must actually coordinate. I've reviewed thousands of supplier contracts over fifteen years. The pattern is depressingly consistent: either contracts contain no meaningful security language, or they include generic "supplier shall maintain reasonable security controls" clauses that are legally meaningless.

Effective supplier agreements need specific, auditable requirements. Instead of "maintain appropriate security," specify "encrypt all data in transit using TLS 1.2 or higher" or "implement multi-factor authentication for all administrative access." Instead of "promptly report security incidents," define "notify customer within 24 hours of discovering any security event affecting customer data."

Your agreements should address several critical areas: information classification and handling requirements specific to your data types, technical security controls appropriate to the access level, incident response procedures including notification timelines, audit rights and evidence requirements, personnel security measures for supplier staff accessing your data, data location and cross-border transfer restrictions, and secure termination procedures including data return and destruction.

The cross-reference to ISO/IEC 27036-2:2022 is crucial here. That standard provides detailed guidance on supplier relationship processes, including specific activities for agreement development and management. When auditing Control 5.20, I look for evidence that organizations have actually tailored their contract templates based on supplier risk tiers and data types, not just copied generic security clauses.

What the Auditor Looks For

Contract templates with specific security requirements by supplier tier
Evidence that legal, procurement, and security teams collaborate on contract development
Documentation of how security requirements vary based on data sensitivity and access levels
Procedures for handling situations where suppliers can't meet required security controls
Regular review and updates of contract security language based on threat evolution

Beyond Tier-1: Control 5.21 and ICT Supply Chain Security

Control 5.21 (formerly A.15.1.3) focuses specifically on the ICT supply chain, and this is where most organizations completely lose visibility. Your primary cloud provider might have excellent security, but what about their infrastructure suppliers? Their software vendors? The hardware manufacturers in their supply chain?

The NotPetya attack spread through a Ukrainian accounting software update. The SolarWinds compromise affected thousands of organizations through a single software supply chain infection. These aren't theoretical risks—they're the new normal. Control 5.21 requires you to consider security throughout the ICT supply chain, not just your direct relationships.

Practical implementation means understanding your suppliers' suppliers, at least for critical services. This doesn't mean auditing every sub-contractor—it means understanding supply chain risks and requiring your primary suppliers to manage them. Ask your cloud provider about their hardware suppliers' security practices. Require your software vendors to maintain software bills of materials (SBOMs) and vulnerability management processes for third-party components.

I've seen organizations implement supply chain risk management by requiring Tier 1 ICT suppliers to maintain their own supplier security programs. This creates a cascade effect where security requirements flow down the supply chain proportionate to risk levels. Your primary supplier becomes responsible for managing their suppliers' security, with contractual obligations to report significant supply chain security events.

Ongoing Vigilance: Control 5.22 Monitoring and Review

Control 5.22 (formerly A.15.2.1) covers monitoring, review, and change management of supplier services. This is where the rubber meets the road—all the careful planning and contracting means nothing if you don't actively monitor compliance and manage changes.

The control specifies thirteen specific monitoring activities, from service performance verification to change management. In practice, effective supplier monitoring requires automated tools and defined processes. You can't manually track compliance across dozens of suppliers—you need systematic approaches.

Implement continuous monitoring where possible. For cloud services, this might mean automated compliance dashboards showing security configurations and access patterns. For software suppliers, it could include vulnerability scanning and license compliance monitoring. For service providers, consider regular security questionnaires and evidence reviews.

The key insight from ISO/IEC 27036-3: establish service level agreements (SLAs) that include security metrics, not just performance metrics. Your cloud provider's uptime SLA is important, but what about their incident response time SLA? Their security patch deployment SLA? Their audit compliance SLA?

Common Implementation Mistakes

Mistake: Treating supplier security as a one-time assessment during procurement.
Reality: Supplier risk profiles change constantly. The vendor with excellent security this year might be acquired, outsourced, or compromised next year.

Mistake: Applying identical security requirements to all suppliers regardless of risk.
Reality: Risk-based supplier management reduces vendor fatigue and focuses resources on actual threats.

What the Auditor Looks For: Evidence Requirements

When auditing supplier security controls, I look for specific evidence that goes beyond policy documents. For Control 5.19, I need to see your supplier inventory with current risk classifications and evidence of how you identify new suppliers entering your environment. Many organizations maintain formal vendor lists but miss shadow IT suppliers or business unit procurement.

For Control 5.20, I examine actual contracts to verify that security requirements match the risk classifications you've established. I also look for evidence of how you handle situations where suppliers can't meet requirements—do you implement compensating controls, accept residual risk, or find alternative suppliers?

Control 5.21 evidence includes documentation of how you assess ICT supply chain risks, particularly for critical suppliers. This might include third-party risk assessments, supplier security certifications, or evidence of supply chain security programs maintained by your primary suppliers.

For Control 5.22, I need evidence of active monitoring, not just processes. This includes monitoring reports, change notifications from suppliers, incident reports and responses, and evidence of regular supplier reviews with documented outcomes.

Cross-Standard Considerations and Cloud Services

Supplier security management intersects with several related standards. ISO/IEC 27017 provides additional guidance for cloud service security, particularly relevant for Control 5.23. ISO/IEC 27018 addresses privacy protection in public cloud services. ISO/IEC 27036 series offers comprehensive supplier relationship management guidance.

For organizations using cloud services extensively, the supplier security controls become particularly critical. Cloud providers are suppliers, but they're suppliers that control fundamental infrastructure. Your cloud security posture depends entirely on your cloud provider's security implementation and your configuration of their services.

The shared responsibility model in cloud computing creates unique supplier security challenges. You're responsible for security in the cloud (your applications, data, access management), while your cloud provider is responsible for security of the cloud (physical security, infrastructure, foundational services). Understanding and managing this division of responsibility is essential for effective supplier security management.

Practical Implementation Roadmap

Start with inventory. You can't manage what you can't see, and most organizations have incomplete supplier visibility. Implement processes to identify all suppliers with access to your information assets, not just IT suppliers. This includes service providers, consultants, partners, and anyone with logical or physical access to your systems or data.

Develop risk-based supplier tiers and corresponding security requirements. Don't try to implement comprehensive supplier security for all vendors simultaneously—prioritize based on risk and implement tier by tier. Focus first on suppliers with access to sensitive data or critical systems.

Integrate supplier security into procurement processes from the beginning, not as an afterthought. Security requirements should be part of vendor evaluation criteria, and security capabilities should influence supplier selection decisions.

Implement ongoing monitoring and review processes. Supplier security isn't a one-time assessment—it requires continuous attention and periodic review. Establish regular review cycles based on supplier risk levels and implemented monitoring based on practical capabilities.

The supplier security controls in A.5.19 through A.5.22 represent fundamental requirements for modern organizations. In an interconnected business environment, your security posture is only as strong as your weakest supplier relationship. These controls provide the framework for managing that reality systematically and effectively.

Need help implementing supplier security management or preparing for your ISO 27001 audit? Connect with our community of security professionals at the IX ISO 27001 Info Hub for practical guidance and implementation support.

Need personalized guidance? Reach our team at ix@isegrim-x.com.