Today, virtually no company provides all of its services entirely on its own. Cloud platforms store business-critical data, external IT service providers manage systems, software vendors supply core applications, and specialized partners handle individual business processes. This collaboration boosts efficiency but also increases a company’s attack surface. After all, a security incident at a service provider can very quickly affect the company itself.
Effective supplier management is therefore much more than just a task for the procurement department. It combines risk management, contract drafting, ongoing monitoring, and emergency preparedness. ISO 27001 also specifically addresses these interdependencies. It calls on companies to manage external relationships not only from an economic perspective but also from the standpoint of information security. It is crucial to assess supplier risks throughout the entire lifecycle of a partnership—from selection to orderly termination.
Why Suppliers Can Pose a Security Risk
External partners are often granted access to data, systems, buildings, or business processes. A cloud provider may process personal and confidential information. A maintenance service provider has privileged remote access. A software vendor provides updates for an application without which core operations would not function. Even if your own company is well protected, vulnerabilities at these partners can have a direct impact on confidentiality, integrity, and availability.
A typical example is a compromised administrator account at an IT service provider. If the provider uses the same account for multiple clients or lacks strong authentication and adequate logging, attackers can gain access to various client systems through the service provider. Another example is the failure of a cloud service. If there are no robust contingency procedures, data exports, or alternatives in place, a disruption at the provider can result in a prolonged service interruption within your own company.
Such supplier risks cannot be fully transferred. Even when a service is outsourced, responsibility for the contracting organization’s own information, processes, and obligations generally remains with the contracting organization. A contract or a certificate from the provider can support the assessment, but it does not replace the contracting organization’s own risk-based review.
What role does ISO 27001 play?
ISO 27001 specifies requirements for an information security management system and includes a reference list of possible measures in Annex A. In the 2022 edition, five controls explicitly address supplier relationships, the ICT supply chain, and cloud services.
A.5.19 and A.5.20: Risks and Contractual Requirements
Control A.5.19 focuses on security in supplier relationships. Organizations should establish appropriate processes to manage risks arising from the use of products and services provided by external suppliers. This begins with identifying relevant partners and assessing them based on their potential impact on the organization.
A.5.20 translates this approach into agreements. Security requirements should not only be known internally but also clearly defined in agreements with the provider. Depending on the level of protection required and the scope of services, these may include provisions regarding access, encryption, security incidents, subcontractors, vulnerabilities, emergency preparedness, audits, and the return or deletion of data.
This makes it clear: Good contract drafting does not begin with a standard clause, but with a specific risk assessment. Only when a company understands its requirements can it effectively negotiate them and monitor them later on.
A.5.21 and A.5.22: Supply Chain and Ongoing Monitoring
A.5.21 broadens the perspective on the supply chain for information and communication technology. A direct contracting party is often itself dependent on manufacturers, data centers, platforms, or open-source components. These subcontracting arrangements and technical dependencies can create additional supplier risks that are initially barely visible to the customer.
A.5.22 makes it clear that the evaluation does not end with the signing of the contract. Services, security certifications, and significant changes must be monitored and reviewed throughout the course of the collaboration. If a provider changes its location, infrastructure, key subcontractors, or scope of services, its risk profile may also change. Supplier management therefore requires fixed review intervals and ad hoc reassessments.
A.5.23: Use Cloud Services in a Controlled Manner
With cloud services, responsibilities are shared between the customer and the provider. A.5.23 therefore addresses processes for the procurement, use, management, and termination of cloud services. Before implementation, it should be clarified which data will be processed, where the processing will take place, which security features are available, and which responsibilities remain with the customer.
The exit phase is also part of the process. Companies should know in advance in what format data can be exported, what deadlines apply, and how to demonstrate that data has been securely deleted after the contract ends. Waiting until the contract is terminated to develop a cloud exit strategy is often too late.
The controls should not be viewed as a rigid checklist that every organization must implement identically. Under ISO 27001, decisions regarding which measures are necessary for an organization’s specific scope are made on a risk-based basis. The selection of controls and any instances where they are not applicable are clearly justified in the Statement of Applicability.
From Onboarding to Exit: A Practical Process
A robust process begins even before the contract is awarded. First, it is important to determine which information, systems, or processes the provider affects. From this, it is possible to determine how critical the service is and what level of scrutiny is required. A supplier of general office supplies requires a different assessment than an operator of the central ERP platform.
For critical partners, the review may include, among other things, existing certifications, their actual scope, security policies, emergency procedures, technical safeguards, and the management of subcontractors. Questionnaires are a useful tool in this context, but they alone do not provide reliable evidence. Where the risk warrants it, statements should be substantiated by appropriate documents, audit reports, test results, or contractual assurances.
Once selected, the identified requirements must be incorporated into the contract, the statement of work, or the security system. For example, it is advisable to establish clear reporting procedures and deadlines for security incidents, rules for administrative access, agreed-upon recovery times, and audit rights. Responsibilities on both sides should also be clearly defined.
During day-to-day operations, effective supplier management links these agreements to measurable controls. This may include regular service meetings, the evaluation of security incidents, the verification of current certifications, the tracking of outstanding actions, and a reassessment of risks in the event of significant changes. If deviations are identified, those responsible must decide whether corrective actions, additional controls, or—if necessary—a change in supplier are required.
Real-World Example: The Cloud Provider with a Valid Certificate
A company wants to implement a new collaboration platform. The provider cites a valid certificate and is therefore initially deemed sufficiently secure. Upon closer examination, however, it becomes apparent that the scope of the certificate covers only a portion of the services offered. Furthermore, questions remain regarding data location, the use of subcontractors, and the recovery of deleted content for the specific platform in question.
The responsible departments therefore verify not only the existence of the certificate, but also its scope and validity. In addition, security requirements are defined for the specific use case, and outstanding issues are addressed through contractual agreements. This example illustrates why information security is not achieved simply by collecting evidence. What matters is whether the evidence aligns with the organization’s own risk profile, the service being used, and the protection needs of the information being processed.
What Companies Can Take Away from the BSI Recommendations
The UP KRITIS best-practice recommendations regarding security requirements for suppliers were developed for critical infrastructure. They take a practical approach: requirements should be selected, documented, and contractually agreed upon based on the level of protection required and the nature of the contracted service. If a requirement is excluded or modified, this decision should also be supported by a clear and comprehensible rationale.
This basic logic is not only helpful for KRITIS companies. Other organizations can also conclude from this that security requirements should not be applied indiscriminately to every provider. A risk-based approach establishes priorities while also preventing critical service providers from being evaluated using a standard questionnaire that is too superficial.
For effective supplier management, this means that the greater the potential damage resulting from an outage, data loss, or unauthorized access, the more specific the selection, agreements, and monitoring must be. This not only makes the processes more verifiable but also strengthens the organization’s actual resilience.
Common Weaknesses in Supplier Management
In practice, the problem rarely lies in the fact that no documentation exists at all. Rather, the link between the individual steps is often missing. The procurement department requests a questionnaire, the IT department reviews the technical integration, and the legal department negotiates the contract—but no one consolidates the results into a comprehensive risk assessment.
Equally problematic is a one-time audit without subsequent monitoring. Certificates can expire, services can change, and new subcontractors can be added. Even identified nonconformities lose their value if there are no designated responsible parties or deadlines for follow-up.
Another weakness is the lack of preparation for disruptions or the end of a contract. Those who do not know how to migrate data, revoke access, and activate alternative services remain dependent despite good preventive measures. Managing supplier risks must therefore also take into account business continuity, incident management, and exit scenarios.
Conclusion: Supplier security is a shared responsibility
Companies can outsource services, but not the responsibility for the associated risks. Suppliers, software vendors, and cloud service providers must therefore be systematically integrated into information security management.
ISO 27001 provides a suitable framework with Controls A.5.19 through A.5.23: risks are assessed prior to awarding a contract, requirements are set forth in the contract, ICT supply chains are taken into account, and services are monitored throughout their entire term. However, practical implementation is crucial. A completed questionnaire or a certificate alone does not guarantee security.
Syngenity® GmbH helps organizations establish and further develop an effective supplier risk management program. This includes risk-based supplier assessments, the implementation of relevant ISO 27001 controls, the definition of appropriate security requirements, and the design of transparent monitoring and governance processes.
After all, an organization’s security does not end at its own corporate boundaries. It extends to the partners on whose services the company relies every day.
