Supplier management in ISO 27001

Since suppliers often have access to information assets that are critical to business operations, the ISO 27001 standard dedicates a full set of organizational controls (5.19–5.23) to managing information security risks in supplier relationships. In this article, we explain these controls and provide a supplier register template.

ISO controls for supplier management

The ISO 27001 standard has five controls that together describe a supplier management process (A5.19 – A 5.23). You should make one supplier review process that implements all these controls together, since these controls are related. The relations between the controls are as follows:

• A5.19 Information security in supplier relationships: this control states that there must be a supplier review process that includes information security. Typically you plan (in your ISMS calendar) an annual supplier review and record results in a supplier register. The register is the evidence of the process that you show in the audit.
• A5.20 Addressing information security within supplier agreements: as a result of the process, there should be requirements from you on your suppliers that you include in your supplier agreements. Note that the GDPR also requires this, so often you will require a data processing agreement.
• A5.21 Managing information security in the ICT supply chain: this controls requires you to think of any sub-suppliers or component suppliers that you suppliers use. You cover these with a subcontractor clause in contracts.
• A5.22 Monitoring, review and change management of supplier services. this control requires you to make the supplier review recurring and to check requirements in case of changes.
• A5.23 Information security for use of cloud services: this control requires you to consider some cloud specific actions, such as supplier exit.

We will first explain the entire process. We then explain each control.

Supplier register template and process

To support these controls in practice, we developed a free Excel supplier register template. Each supplier is recorded on a single line. You use this template as follows:

• You identify all suppliers with an impact on information security. This will include IT suppliers, SaaS suppliers but also professional services or services that require you to share information with;
• For each supplier, include contact details and service description;
• For each supplier: your requirements. We recommend that you have formal requirements and practical requirements. Formal requirements are for instance that they have an ISMS and formal certifications such as ISO 27001 or Security Verified, or that there is a GDPR Data Processing Agreement. A practical requirements would be an uptime target, or that they are not the cause of incidents or disruptions.

Once you have requirements for all your suppliers, you must check that suppliers meet your requirements. E.g., if you require an ISO 27001 certificate, you must annually download or request the certificate. If you require a certain uptime level (e.g., 99.5%), you must record the actual uptime (e.g., 99.745%). You can then check if the supplier meets your requirements. If they do not, you must take action: send a warning via email, schedule a meeting or ultimately change suppliers. This is shown in the screenshot below. As you can see it is repeated annually.

Note that any auditor will not check your suppliers for you. You must complete the supplier review, and the auditor will check that you have a register like this with recent supplier assessments.

5.19 Information security in supplier relationships

Control 5.19 requires organisations to define and implement processes to manage information security risks related to supplier products and services. It can be implemented by describing a clear procedure on what, how and when information security requirements are decided and reviewed:

• which types of suppliers exist (e.g. IT, cloud, consultants)

• which information security requirements apply to each type

• how compliance is assessed and reviewed internally

Typical requirements include, incident notification agreements and response obligations, NDAs, documentation of how services are provided and supported, or more personalized processes like logistics or delivery (SLA). You decide per category of supplier the right requirements for you.

In practice. Add a procedure within your procedures document. The most simple and practical set of requirements for small organizations can be three-four documented requirements such as an ISO27001 or SOC2 certification for a large supplier (e.g., for a cloud or platform provider), a processing agreement when handling personal data (e.g., for CRMs) and a sound privacy policy (e.g., for smaller services); then, decide on two-three practical requirements relevant to you and that are feasible to check periodically, such as no recent data breaches or serious service outages. This is shown in practice in our supplier register template and the Notion for GDPR article.

5.20 Addressing information security within supplier agreements

Control 5.20 ensures that the established information security requirements are contractually agreed with each supplier. Any supplier should formally agree to meet your requirements. They  can do this via:

• Their standard service level agreement if they have one. Carefully review that it contains what you need, e.g backups, screening, uptime.

• A data processing agreement or DPA addendum. This will also cover information security and is often sufficient

• An information security policy, information security management system or even ISMS certification.

In practice. Enter, per supplier, the chosen requirements in the supplier register and coordinate with supplier, if possible. As part of your supplier policy or procedures, a ‘documented requirement’ can be indeed the presence of a valid ISO27001 certification, a signed DPA, DPA addendum or a sound privacy policy.

5.21 Managing information security in the ICT supply chain

Control 5.21 extends the scope beyond direct suppliers to the ICT supply chain as a whole. Organisations are expected to define security requirements that apply throughout the chain, particularly for business-critical suppliers. This may include:

• traceability of components or services in the supply chain;

• minimum security baselines that must be maintained at each level;

• evidence of compliance, such as ISO 27001 or SOC 2, or other relevant certifications.

In practice. Consider to make sure that every contract states that the requirements remain unchanged when a subcontractor is used.

5.22 Monitoring, review and change management of supplier services

Even with agreements in place, suppliers can change their services over time or have incidents. Control 5.22, therefore requires organisations to monitor, review and manage changes in supplier services and security practices.

Typical monitoring activities include:

• annual review of certifications and contractual commitments;

• tracking service-level indicators such as uptime;

• recording incidents or deviations from agreed requirements.

• Name changes of take-overs of suppliers.

In practice. The supplier relationship policy, or your procedures, should include what to do if a supplier fails to meet the chosen requirements. For example, adequate uptime and evidence of recertification for a cloud provider would both indicate that the supplier meets information security requirements. Consider also a clear pentest report or a reaction within 24 hours from your external data protection officer, if any. Make sure to schedule regular the check in you ISMS yearly plan and discuss with an IS meeting or workshop whether there are any changes.

5.23 Information security for use of cloud services

This is an important new control in the 2022 version of ISO27001. Cloud services deserve special attention because they often form a core part of the organisation’s infrastructure: if they go out for a massive outage, your whole business goes out too. Control 5.23 requires processes for the acquisition, use, management and exit of cloud services. Key elements typically include:

• clear acquisition criteria (e.g. EU/EEA hosting, MFA support, DPA in place);

• defined roles, responsibilities and procedure for cloud administrators (ownership)

• a documented exit strategy, including data export and deletion.

Whether using SaaS, PaaS or IaaS, cloud services should support the organisation’s desired level of information security.

In practice. Define a list of most important cloud providers in your procedures/policies, and describe the your acquisition requirements such as MFA support, how long the provider existed, but also ISO27001 certification. An important note concerns the exit strategy: explicitly describe your requirements for an exit strategy, such as export capabilities or external redundancy for critical assets. Finally, describe in the procedures the way you manage security aspects within the use of the cloud provider by linking to other controls, for example, how access control is implemented or how usage and costs are monitored.

Cover: Hamburg port – Pavlo Burda