ISO/IEC 27036 Supplier Relationships Guide

ISO/IEC 27001 tells you to manage information security in supplier relationships, but says little about how; ISO/IEC 27036 is the multi-part standard that fills that gap. It covers both sides of the relationship, the acquirer buying a product or service and the supplier providing it, and extends from general requirements to hardware, software and services supply chains and to cloud services. This guide explains what each of the four parts covers and which edition is current, how to turn the standard into a working programme, what evidence auditors and customers expect, and where integration tokens, OAuth apps and supplier service accounts fit. It is written for security, GRC and procurement practitioners who already run, or are building, an ISO/IEC 27001 information security management system (ISMS).

Key takeaways

Four parts, different jobs. Part 1 (2021) gives concepts, Part 2 (2022) sets requirements, Part 3 (2023) guides hardware, software and services supply chain security, and Part 4 (2016) covers cloud services.
The series was renamed. Current editions sit under "Cybersecurity, Supplier relationships"; the 2013 and 2014 editions titled "Information security for supplier relationships" are withdrawn, so update policy citations.
It works inside an ISMS. ISO's own summary of Part 2 assumes foundational processes such as risk management and information security are already in place, so it is best used to deepen ISO/IEC 27001 Annex A controls 5.19 to 5.23 rather than as a standalone programme.
Both parties have obligations. The standard is written for acquirers and suppliers, which makes it useful for designing contract schedules both sides can evidence.
Machine access is supplier access. A supplier's OAuth tokens and API keys into your tenants are part of the relationship and must be inventoried, scoped and revoked at exit like any other supplier access.

What it is and who it applies to

ISO/IEC 27036 is published by ISO/IEC JTC 1/SC 27, the committee responsible for the ISO/IEC 27000 family. ISO describes Part 2 as applicable to all organisations regardless of type, size or nature, and lists a wide range of supply arrangements in scope: manufacturing or assembly, business process procurement, software and hardware components, knowledge process procurement, build-operate-transfer arrangements and cloud computing services.

Part	Current edition	Title	Nature	Status on ISO catalogue
Part 1	ISO/IEC 27036-1:2021 (edition 2, 12 pages)	Overview and concepts	Introductory guidance; introduces concepts detailed in other parts	Published; under systematic review since July 2026; replaced the 2014 edition
Part 2	ISO/IEC 27036-2:2022 (edition 2, 38 pages)	Requirements	Requirements for defining, implementing, operating, monitoring, reviewing, maintaining and improving supplier and acquirer relationships	Published June 2022; replaced the 2014 edition
Part 3	ISO/IEC 27036-3:2023 (edition 2, 35 pages)	Guidelines for hardware, software, and services supply chain security	Guidance on dispersed, multi-layered supply chains and life cycle integration	Published June 2023; replaced the 2013 ICT supply chain edition
Part 4	ISO/IEC 27036-4:2016 (edition 1)	Guidelines for security of cloud services	Guidance for cloud service customers and providers	Published; reviewed and confirmed in 2022

Who should use which part:

Acquirers with an ISMS: Part 2 as the requirements baseline for the supplier management process, with Part 1 for shared vocabulary.
Software, hardware and managed service suppliers: Part 3, because it ties supply chain security to ISO/IEC/IEEE 15288 (system life cycle) and ISO/IEC/IEEE 12207 (software life cycle) processes and supports ISO/IEC 27002 controls.
Cloud customers and providers: Part 4, read alongside ISO/IEC 27017. ISO notes that Part 4 does not explain how a provider should run its own security, which ISO/IEC 27002 and ISO/IEC 27017 cover.
Continuity planners: Parts 3 and 4 explicitly exclude business continuity and resiliency and point to ISO/IEC 27031, so supplier resilience needs another source. See the Third-Party Concentration Risk Guide.

Small versus large organisations: a small acquirer with a dozen critical suppliers can apply Part 2 through one procedure, one tiering rule and a standard contract schedule. A large or regulated organisation will need Part 3 for software and hardware supply chains, Part 4 for cloud, and a register that can also feed regulatory reporting such as the DORA register of information.

Structure and key requirements

The standard follows the life of a relationship rather than a list of technical controls. The themes below are how practitioners typically apply it; consult the purchased text for exact clause wording before quoting it in an audit.

Life cycle stage	What the acquirer does	What the supplier does	Typical artefact
Planning	Decides what is being sourced, the information and systems involved, and the risk appetite	Understands the customer's security expectations before bidding	Sourcing risk assessment
Selection and due diligence	Assesses supplier capability in proportion to risk	Provides evidence: certificates, scope statements, reports, policies	Due diligence record, completed questionnaire
Agreement	Writes security requirements, notification duties, audit rights and exit terms into the contract	Accepts measurable obligations and flows them down to its own suppliers	Security schedule, data processing terms
Management and monitoring	Reviews performance, changes and incidents	Reports incidents, changes and subcontractor use	Review minutes, findings tracker
Termination	Recovers or confirms destruction of data, removes access	Returns or destroys data, surrenders credentials	Exit checklist, destruction certificate

Part 3: hardware, software and services

The 2023 edition widened the old "ICT supply chain" focus to hardware, software and services. ISO summarises its aims as gaining visibility into and managing risk in physically dispersed, multi-layered supply chains, responding to risks that could affect organisations using the products and services, and integrating security into system and software life cycle processes. In practice that means asking suppliers about their own suppliers, their build and release processes and their vulnerability handling, not only their office controls. See the Software Supply Chain Security Guide and the SBOM Guide.

Part 4: cloud services

Part 4 helps cloud service customers gain visibility into the risks of using cloud services and manage them, and helps providers respond to risks that affect their customers. It pairs naturally with the shared responsibility model: the contract and the provider's documentation should make clear which controls the customer must operate itself, including identity configuration and the integrations it connects. See the ISO/IEC 27017 Cloud Security Controls Guide.

Identity and NHI requirements

ISO/IEC 27036 is not an identity standard, but almost every supplier relationship it covers involves access. Much of that access is now non-human: an integration token held by a SaaS vendor, an OAuth app with read access to mail, a managed service provider's service account, an API key issued to a payments partner. Treat these as part of the relationship record.

Inventory: record, per supplier, every human account, service account, OAuth grant, API key and certificate it holds into your environment, with an internal owner. See the SaaS and OAuth App Governance Guide.
Approval: stop end users granting broad scopes to third-party apps. In Microsoft Entra ID, the admin consent workflow (Enterprise apps, Consent and permissions, Admin consent settings) routes requests to designated reviewers; only Global Administrators can approve apps requesting Microsoft Graph application permissions.
Contract terms for credentials: require the supplier to describe how it stores customer tokens and secrets, to notify you when that store may be compromised, and to support revocation and rotation on request.
Technical limits: least-privilege scopes, token expiry, IP restrictions to the supplier's published ranges and per-integration logging. The Salesloft Drift breach shows why: tokens stored in one vendor's cloud environment gave the attacker access to Salesforce data at hundreds of customer organisations.
Human supplier access: contractors and outsourced help desks need time-bound accounts, phishing-resistant MFA and verified reset procedures. See the Third-Party Access Guide.
Exit: revoke every token, key and account the supplier holds and confirm it in the exit record. See the NHI Offboarding and Decommissioning Guide.

Implementation steps

Buy and scope. Obtain the current editions (Part 1:2021, Part 2:2022, Part 3:2023, Part 4:2016) and decide which parts apply: Part 2 always, Part 3 if you buy or build software and hardware, Part 4 if you use or provide cloud services.
Gap-assess against your ISMS. Compare your existing supplier procedure and ISO/IEC 27001 Annex A 5.19 to 5.23 controls with Part 2. Record gaps in the risk register.
Build the supplier register. Combine procurement, finance, SSO and SaaS discovery data. For each supplier record service, data held, systems connected, non-human credentials held, criticality tier and owner.
Define tiers and assessment depth. For example: tier 1 (critical service or sensitive data) gets full evidence review and annual reassessment; tier 3 (no data, no access) gets a short declaration. See the Security Questionnaires Guide.
Write the contract schedule. Security requirements, breach notification period, subcontractor notice, right to audit, credential handling, data return and destruction. Agree it with legal and pilot it on two or three renewals before making it standard.
Apply Part 3 to software suppliers. Add questions on secure development, build integrity, SBOM provision and vulnerability disclosure for suppliers whose software runs in your environment.
Stand up monitoring. Reassessment by tier, review of certificates and reports on expiry, and alerts on supplier incidents. Track findings to closure.
Rehearse exit and incident. For one critical supplier, walk through a breach notification and an exit: who revokes which credentials, how data is recovered, how long it takes. Fix what fails, then repeat for other critical suppliers.

Rolling back: if a new contract schedule stalls renewals, keep the mandatory clauses (notification, data return, credential revocation) and move the rest to a negotiated annex rather than dropping the schedule.

Evidence and assessment

ISO/IEC 27036 is usually evidenced through an ISO/IEC 27001 audit of supplier controls, or through customer assessments of a supplier. Auditors and customers typically look for the artefacts below.

Evidence	What good looks like	Common weakness
Supplier management procedure	Covers the full life cycle, owned and reviewed	Covers onboarding only
Supplier register	Complete, tiered, includes credentials held and data processed	Built from procurement only, misses SaaS and OAuth apps
Due diligence records	Depth matches tier, evidence checked for scope and date	Certificates accepted without checking the scope covers the service bought
Contracts	Security schedule signed, flow-down to subcontractors	Supplier's standard terms with no notification duty
Monitoring records	Reassessments on schedule, findings closed	No activity after signature
Exit records	Access revoked, data returned or destroyed, confirmed	Accounts and tokens still active months later

Metrics:

Share of suppliers with data or system access that are registered and tiered.
Share of tier 1 suppliers reassessed within the cycle.
Share of tier 1 contracts with the full security schedule.
Number of third-party OAuth grants and integration tokens with no owner or no expiry.
Hours from a supplier breach notification to revocation of all its credentials.
Days from contract end to confirmed access removal and data destruction.

Mapping to other frameworks

ISO/IEC 27036 theme	ISO/IEC 27001:2022 Annex A	NIST CSF 2.0	NIST SP 800-53 Rev. 5	CIS Controls v8.1
Supplier policy and programme	5.19 Information security in supplier relationships	GV.SC-01, GV.SC-03	SR-1, SR-2	15.2
Inventory and criticality	5.19	GV.SC-04	SA-9	15.1, 15.3
Due diligence	5.19	GV.SC-06	SR-6, SA-4	15.5
Agreements	5.20 Addressing information security within supplier agreements	GV.SC-05, GV.SC-02	SR-3, SR-8	15.4
Hardware, software, services supply chain (Part 3)	5.21 Managing information security in the ICT supply chain	GV.SC-09	SR-3, SR-5, SR-11	16 (application software security)
Monitoring and change	5.22 Monitoring, review and change management of supplier services	GV.SC-07	SR-6, SA-9	15.6
Cloud services (Part 4)	5.23 Information security for use of cloud services	GV.SC-07	SA-9, AC-20	15.4
Incident and termination	5.20, 5.22	GV.SC-08, GV.SC-10	SR-8	15.7

Regulatory overlaps:

US banking: the June 2023 interagency guidance from the Federal Reserve, FDIC and OCC describes the same life cycle (planning, due diligence and selection, contract negotiation, ongoing monitoring, termination) and expects contracts to address subcontractor notice, timely breach notification and the return or destruction of data.
EU financial sector: DORA requires financial entities to keep a register of information on ICT third-party arrangements; the templates are set by Commission Implementing Regulation (EU) 2024/2956, in force since 22 December 2024. A 27036-style register can feed it. See the DORA Guide.
US federal and its suppliers: NIST SP 800-161 Rev. 1 is the detailed cyber supply chain risk management (C-SCRM) companion, with C-SCRM strategy, policy and plan guidance and a scoping questionnaire. See the NIST SP 800-161 Cyber Supply Chain Risk Management Guide.
UK: the NCSC supply chain guidance sets 12 principles across four stages: understand the risks, establish control, check your arrangements, and continuous improvement.

Common pitfalls

Citing withdrawn editions: policies still reference ISO/IEC 27036-3:2013 or the 2014 Parts 1 and 2. Auditors notice, and the 2023 Part 3 scope is wider.
Treating it as a questionnaire standard: the value is in contracts, monitoring and exit, not in a longer form at onboarding.
Leaving integrations out of scope: OAuth apps and integration tokens never go through procurement. The Gainsight Salesforce breach involved 285 OAuth tokens issued between 2017 and 2023 that were still usable against customer tenants.
Assuming Part 4 covers resilience: it excludes business continuity; plan supplier failure and exit separately.
Accepting certificates at face value: an ISO/IEC 27001 certificate whose scope excludes the service you buy is weak evidence.
Forgetting the supplier's help desk: outsourced support that can reset credentials is part of the relationship, as the Marks and Spencer cyberattack illustrated.

Practitioner checklist

Update policy references to ISO/IEC 27036-1:2021, 27036-2:2022, 27036-3:2023 and 27036-4:2016.
Gap-assess your supplier procedure against Part 2 and Annex A 5.19 to 5.23.
Build one supplier register that records data held, systems connected and non-human credentials held.
Tier suppliers and set assessment depth and reassessment frequency per tier.
Adopt a security contract schedule with notification, subcontractor, audit, credential and exit terms.
Apply Part 3 questions to software and hardware suppliers, including SBOM and vulnerability handling.
Route third-party app consent through an admin approval workflow and set token expiry and IP restrictions.
Keep a revocation runbook per critical supplier and test it.
Report the six metrics to the ISMS management review.

ISO/IEC 27036 Supplier Relationships Guide: Securing the Supply Chain