ISO/IEC 27036 Series: ISO/IEC 27036 Series – Tutorial (about 60 minutes)

The ISO/IEC 27036 series is a family of international standards about one stubborn problem: your information is only as safe as the suppliers who touch it. It helps organisations that buy products and services, and organisations that supply them, to understand, agree and manage the information security risks that come with every supplier relationship, from a cleaning contractor with badge access to a cloud platform running your core business. Procurement, security, risk, legal and vendor-management professionals use it. After this tutorial you will be able to explain what each part of the series covers, run a supplier relationship through its security lifecycle, and connect the series to ISO/IEC 27001 and other supply-chain frameworks.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: ISO/IEC 27036 is published jointly by ISO and IEC and maintained by the joint technical committee ISO/IEC JTC 1/SC 27 (information security, cybersecurity and privacy protection). It is a series, not one document, and each part has its own edition. As verified on 2026-10-29 in the IEC Webstore catalogue (the ISO catalogue blocks automated checks), the current parts are: Part 1: Overview and concepts, ISO/IEC 27036-1:2021 (second edition, published September 2021, replacing the 2014 first edition); Part 2: Requirements, ISO/IEC 27036-2:2022 (second edition, published June 2022, replacing 2014); Part 3: Guidelines for hardware, software, and services supply chain security, ISO/IEC 27036-3:2023 (second edition, published June 2023, replacing 2013); and Part 4: Guidelines for security of cloud services, ISO/IEC 27036-4:2016 (still the first edition). All four are listed as published and current, and no replacement project was listed for any part at the time of checking. Parts 1 to 3 carry the newer series title "Cybersecurity – Supplier relationships"; Part 4 still carries the older title "Information technology – Security techniques – Information security for supplier relationships". Always check the official catalogue before you cite a part, because each one is reviewed and revised on its own schedule.

Who it is for: information security and risk staff, procurement and vendor managers, contract and legal advisers, IT and cloud architects who select providers, internal auditors, and people working for suppliers who must answer customers' security questions.

Prerequisites: none. A basic idea of what information security means (protecting confidentiality, integrity and availability) and how a purchasing process works will help. Every term from the series is explained when it first appears.

By the end of this tutorial:

You will be able to explain why supplier relationships create information security risks that internal controls alone cannot handle.
You will be able to describe the purpose and audience of each of the four parts of the series.
You will be able to walk a supplier relationship through planning, selection, agreement, management and termination, naming the security work in each step.
You will be able to explain why visibility shrinks as a supply chain gets deeper and what acquirers and suppliers can do about it.
You will be able to choose suitable assurance evidence for a supplier and explain why there is no certificate for the series itself.
You will be able to relate the series to ISO/IEC 27001 and 27002, ISO/IEC 27017, NIST SP 800-161 and the NIST Cybersecurity Framework.

Lesson 1 – Why supplier relationships need their own security standard

Nobody works alone any more

Almost every organisation depends on others to run. A bank rents data-centre space, buys a core banking package, uses a cloud email service, outsources card printing and hires contractors to write code. A hospital relies on medical device makers, a billing bureau and a laboratory network. A small online shop runs on a hosted e-commerce platform, a payment provider and a delivery company. Each of those relationships exists for good reasons: lower cost, access to expertise the organisation does not have, the ability to scale quickly, or simply the wish to focus on what the organisation does best.

Every one of those relationships also opens a door. The supplier may store or process your information, connect to your network, ship hardware that sits inside your systems, write software that you run, or provide a service whose failure stops your business. When you hand over work, you do not hand over accountability. If a payroll bureau leaks salary data, regulators and employees will still look at the employer. If a software update from a trusted vendor carries malicious code, the organisations that installed it suffer the breach.

Lessons from real incidents

The last fifteen years have produced many well-known examples of supply-chain compromise: attackers entering a retailer's network through the credentials of a heating and ventilation contractor; tampered software updates distributed by a widely used IT management vendor; ransomware spread to hundreds of companies through a managed service provider's remote management tool; and vulnerable open-source components pulled into thousands of products without anyone keeping track. These events have different technical details, but they share a pattern. The victim's own controls were not the weak point; the weakness sat with a supplier, or a supplier's supplier, where the victim had little visibility and little direct control.

Regulators have reacted. European rules such as the NIS2 Directive and the Digital Operational Resilience Act (DORA) for the financial sector expect organisations to manage security risks from their suppliers and ICT third-party providers. Many national cybersecurity strategies and public-sector buying rules ask the same. Organisations therefore need a structured, defensible way to manage supplier security, and suppliers need a common language to explain what they do.

What the series is for

The ISO/IEC 27036 series provides that structure. Its purpose is to help organisations protect their information and information systems in the context of supplier relationships. It looks at the relationship from both sides: the acquirer, which obtains a product or service, and the supplier, which provides it. That two-sided view matters. A supplier is itself an acquirer of components and services from others, so the same organisation often plays both roles at once.

The series grew out of the ISO/IEC 27000 family, which is best known for ISO/IEC 27001 (requirements for an information security management system, or ISMS) and ISO/IEC 27002 (guidance on information security controls). Those standards already say that an organisation must address information security in supplier relationships, but they say it in a few controls. The 27036 series expands those few controls into a full treatment: why relationships are risky, what processes an organisation needs, how supply chains for hardware, software and services should be secured, and what is special about cloud services.

Scope and boundaries

The series applies to any organisation, whatever its type, size or sector, and to any kind of supplier relationship: buying products, buying services, outsourcing business processes, acquiring software and hardware components, build-operate-transfer arrangements and cloud services. It is technology-neutral. It does not tell you which security products to buy or which questionnaire to send.

Some topics are deliberately left to other standards. Business continuity and resilience issues in the supply chain are out of scope for Parts 3 and 4, which point to ISO/IEC 27031 for ICT readiness for business continuity. Part 4 also does not tell a cloud provider how to run its own security internally; it points to ISO/IEC 27002 and ISO/IEC 27017 for that. Physical cargo security and logistics are covered more directly by ISO 28000. Keeping these boundaries in mind prevents a common mistake: expecting one series to answer every supply-chain question.

Lesson 2 – Key concepts and vocabulary

Some of these terms are defined formally in the series (for example acquirer, supplier and supplier relationship); others, such as tier and flow-down, are common industry vocabulary used when applying it. The explanations below are plain-language paraphrases to help you read the standards and talk about them with colleagues.

Acquirer – the party that obtains a product or service from another party. Also called the customer or buyer. In a cloud context the acquirer is the cloud service customer.
Supplier – the party that provides a product or service to an acquirer. Also called the vendor, provider or third party. Outsourcing partners, contractors, software vendors and cloud providers are all suppliers.
Supplier relationship – the agreement and ongoing interaction between an acquirer and a supplier to deliver a product or service, from first planning until after it ends. The series treats the relationship, not just the contract, as the thing to manage.
Supplier relationship instance – one specific relationship with one supplier for one purpose, for example "managed firewall service from Supplier X". An organisation has many instances running at the same time.
Supply chain – the set of organisations linked by supplier relationships that together produce and deliver a product or service. Your supplier's suppliers are part of your supply chain even if you never sign anything with them.
ICT supply chain – a supply chain for information and communication technology products and services: hardware, software, networks and the services built on them. Part 3 addresses it directly.
Upstream and downstream – direction words. Upstream means towards the original producers of components (the suppliers of your suppliers); downstream means towards the final users of a product or service.
Tier – the distance of an organisation from the acquirer. A tier 1 supplier contracts directly with you; a tier 2 supplier serves your tier 1 supplier, and so on.
Visibility – the degree to which an acquirer can see who is involved in its supply chain, what they do, and how well they protect information. Visibility usually falls as tiers get deeper.
Flow-down – the practice of passing security requirements from one contract to the next tier's contract, so that a sub-supplier is bound by obligations similar to those the supplier accepted.
Provenance and traceability – knowing where a component or piece of code came from and being able to follow its path through the chain. Both help detect counterfeit or tampered items.
Supplier relationship agreement – the contract, service level agreement, statement of work or other binding document that sets out what each side will do, including security requirements.
Criticality – how much harm the acquirer would suffer if the supplier failed, was compromised or disappeared. Criticality decides how much assurance effort a supplier deserves.
Assurance – the confidence, based on evidence, that a supplier meets agreed security requirements. Evidence ranges from a self-assessment questionnaire to an independent audit.

Why visibility is the central problem

Picture a supply chain as a tree with you at the top. You can negotiate directly with your tier 1 suppliers, inspect their premises and write clauses into their contracts. Beyond them, you depend on what they tell you and what they require of their own suppliers. A software product you buy may include dozens of open-source libraries maintained by volunteers you will never meet. A cloud service may run on infrastructure from another provider, supported by a subcontracted help desk in a different country.

Figure 1 – A multi-tier supply chain: the acquirer contracts only with tier 1, so visibility and leverage weaken at every deeper tier.

This is why the series stresses two complementary ideas. First, the acquirer should use the levers it does have: requirements in the agreement, the right to ask for information, and flow-down obligations that push expectations to deeper tiers. Second, the supplier should take responsibility for managing its own upstream supply chain and be transparent about it. Neither side can solve the problem alone.

Typical risks in supplier relationships

The risks fall into a few families. Information risks arise when a supplier stores, processes or can see your data and fails to protect it. Access risks arise when a supplier has accounts, network connections or physical access to your premises. Product integrity risks arise when hardware or software is counterfeit, tampered with, or built with poor practices that leave vulnerabilities. Dependency risks arise when you cannot easily replace a supplier, so its failure, takeover or price change affects you directly. Concentration risks arise when many of your services, or many organisations in a sector, rely on the same provider. Finally, legal and jurisdiction risks arise when data moves to countries with different laws, or when contracts are silent on who must do what after a breach.

Lesson 3 – Structure of the series

The series is designed so that you can start with the overview and then go to the part that fits your situation. Part 1 is the entry point. Part 2 is the core and the only part written as requirements. Parts 3 and 4 are guidance documents for two special kinds of supplier relationship.

Figure 2 – How the four parts fit together: Part 1 introduces the concepts, Part 2 sets the requirements, and Parts 3 and 4 add guidance for ICT supply chains and cloud services.

Part 1 – Overview and concepts

Part 1 is short and readable. It explains why organisations enter supplier relationships, the main types of relationship (for products, for services, in the ICT supply chain and for cloud services), the information security risks and threats those relationships bring, and the basic approach to managing those risks. It also introduces the special considerations of ICT supply chains and gives a map of the other parts. It addresses both acquirers and suppliers. Read Part 1 first if you are new to the subject or need to brief management.

Part 2 – Requirements

Part 2 is the heart of the series. It specifies fundamental information security requirements for defining, implementing, operating, monitoring, reviewing, maintaining and improving supplier and acquirer relationships. Note the word "requirements": unlike the other parts, Part 2 uses mandatory language, so an organisation can claim conformity with it and an acquirer can require a supplier to follow it.

Part 2 covers any kind of procurement and supply, including manufacturing or assembly, business process procurement, knowledge process procurement, software and hardware components, build-operate-transfer and cloud services. It assumes that the organisation already has, or is actively planning, foundational processes such as business management, risk management, operational and human resource management and information security. In other words, it expects to build on existing management processes, such as an ISMS, rather than replace them.

The requirements are organised in two layers, which is the most useful idea to take from the structure of Part 2.

Organisation-level processes (Clause 6, information security in supplier relationship management) set up supplier relationship management once for the whole organisation. They borrow the process groups of the systems lifecycle standard ISO/IEC/IEEE 15288 (agreement processes, organisational project-enabling processes, technical management processes and technical processes) and describe the security aspects of each. Examples are the acquisition and supply processes, human resource management (roles and competence), risk management applied consistently to suppliers, and information management for the records needed to manage suppliers.
Relationship-level processes (Clause 7, information security in a supplier relationship instance) apply to each individual supplier relationship instance across its lifecycle: planning the relationship, selecting the supplier, agreeing the terms, managing the relationship while it runs, and terminating it. For each step, Part 2 states objectives, inputs, activities and outputs for the acquirer and the supplier.

Informative annexes map Part 2 to the ISO/IEC/IEEE 15288 processes and to the ISO/IEC 27002 controls, which helps an organisation that already runs an ISMS see where each requirement fits.

Figure 3 – The two layers of Part 2: organisation-wide processes in Clause 6, grouped as in ISO/IEC/IEEE 15288, provide the method that each supplier relationship instance then follows through its own Clause 7 lifecycle.

Part 3 – Guidelines for hardware, software and services supply chain security

Part 3 gives guidance to acquirers and to suppliers of hardware, software and services on three things: gaining visibility into the risks caused by physically dispersed, multi-layered supply chains; responding to those risks when they can affect organisations using the products and services; and building information security into the system and software lifecycle processes described in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, while supporting the controls in ISO/IEC 27002. Typical concerns include counterfeit parts, malicious tampering or inserted code, theft of designs, poor development practices that leave vulnerabilities, and loss of track of what components a product contains. The second edition of 2023 updated the first edition of 2013.

Part 4 – Guidelines for security of cloud services

Part 4 helps cloud service customers and cloud service providers gain visibility into the information security risks of using cloud services, manage those risks, and respond to risks that are specific to acquiring or providing cloud services. It looks at the cloud relationship from the customer's point of view and addresses what to consider when choosing, contracting and monitoring a cloud service. It explicitly does not explain how a provider should implement and operate its own security; that is the job of ISO/IEC 27002 and ISO/IEC 27017. Part 4 dates from 2016, so read it together with newer cloud guidance.

How to read the series

Part	Type	Main question it answers	Typical reader
Part 1	Overview	Why are supplier relationships risky and what are the concepts?	Anyone new to the topic, managers
Part 2	Requirements	Which processes must an acquirer or supplier have?	Security, procurement and vendor-management leads, auditors
Part 3	Guidelines	How do we secure ICT products and services through their supply chain?	Product security, engineering, hardware and software buyers
Part 4	Guidelines	What is specific about acquiring and providing cloud services?	Cloud architects, cloud procurement, cloud providers

Lesson 4 – How it works in practice: the supplier relationship lifecycle

The most practical way to apply the series is to follow the lifecycle of a single supplier relationship and ask, at each step, what security work is needed and who does it. The steps below follow the logic of Part 2, explained in practical terms. They are not a copy of the standard's text; use them as a working model and check the standard for the precise requirements.

Figure 4 – The lifecycle of one supplier relationship instance, with the loops that keep security current while the relationship runs.

Step 1 – Planning the relationship

Security starts before anyone talks to a supplier. The acquirer decides what it wants to buy and why, and at the same time works out what information, systems and processes the supplier will touch. It classifies that information, identifies the risks of putting it in another party's hands, and decides how critical the relationship will be. From that analysis it derives security requirements: for example, encryption of data, background checks for staff, logging, incident notification within a set time, location of data, and the right to audit. The acquirer also decides how it will judge whether a supplier meets those requirements. If planning is skipped, security becomes a late negotiation item that is easy to trade away for price.

Step 2 – Selecting the supplier

During selection, the security requirements become part of the request for information or proposal, and candidate suppliers are evaluated against them alongside cost and functionality. Evaluation methods should match criticality: a low-risk supplier may simply confirm a short list of controls, while a critical one may be asked for independent audit reports, a detailed questionnaire, evidence of past incident handling, an on-site visit or a technical test. Good selection also looks at the supplier's own supply chain: which subcontractors it uses, where they are, and how it manages them. The output is a supplier choice made with the security risk understood, and a list of any gaps that need to be closed or accepted.

Step 3 – Agreeing the terms

The agreement turns expectations into obligations. Typical security content includes the requirements themselves; how the supplier will demonstrate compliance; incident reporting duties and timelines; cooperation during investigations; rules for subcontracting and flow-down; data location and transfer limits; change notification; vulnerability handling and patching commitments; audit and inspection rights; liability; and what happens at termination. Both sides should understand who is responsible for what, especially where responsibilities are shared, as in cloud services. Part 2 treats the agreement as a process rather than a document: the parties negotiate, record and sign, and they keep the agreement under review as circumstances change.

Step 4 – Managing the relationship

This is the longest step and the one most often neglected. The acquirer monitors the supplier's performance against the agreement, reviews evidence periodically (for example yearly for a critical supplier), tracks incidents and how they were handled, and watches for changes. Changes are where many risks appear: the supplier is bought by another company, moves a service to a new data centre, adds a subcontractor, changes a key product, or suffers financial trouble. Each change should trigger a fresh look at the risk and, where needed, a renegotiation of terms. The supplier, for its part, keeps its controls running, reports incidents and changes promptly, and manages its own upstream suppliers. Regular meetings with a named owner on each side help keep the relationship healthy.

Step 5 – Terminating the relationship

Every relationship ends, whether by plan, by contract expiry or suddenly because of a dispute or the supplier's failure. A secure ending means the acquirer's information is returned in a usable form or securely destroyed, with confirmation; physical and logical access rights (accounts, VPN links, badges, keys and certificates) are revoked; assets are recovered; and obligations that survive the contract, such as confidentiality, are remembered. Service must also continue: the acquirer needs a transition to a new supplier or back in-house without a gap in protection. The time to plan the exit is during planning and agreement, not on the day the relationship ends.

The supplier's side

The series is not only for buyers. A supplier that adopts it designs its offering so that it can meet typical acquirer requirements, documents its controls, has a process to answer security questions consistently, notifies customers of incidents and changes, and applies the same lifecycle to its own suppliers. Suppliers that do this well spend less time on one-off customer questionnaires and win trust faster.

Roles and artefacts

Supplier security is a team effort. Typical roles include a business owner for each relationship, who is accountable for its value and risk; procurement, who runs selection and contracting; information security, who sets requirements and assesses evidence; legal, who drafts clauses; and internal audit, who checks that the process works. Useful artefacts include a supplier inventory with criticality ratings, a requirements catalogue by criticality, standard contract clauses, an assessment record for each supplier, a review calendar, an incident log, and exit plans for critical suppliers.

Lesson 5 – Assessment, certification and compliance

Is there a 27036 certificate?

The short answer is no, not in the way that people are certified to ISO/IEC 27001. ISO and IEC write standards; they do not certify organisations to any of them. Accredited third-party certification exists for management system standards such as ISO/IEC 27001, and at the time of writing there is no widely recognised accredited certification scheme for the ISO/IEC 27036 series itself. Be cautious with any claim of being "27036 certified" and ask what was actually assessed, by whom and against what.

That does not make the series weak. It is used in three main ways for assurance and compliance:

Inside an ISO/IEC 27001 ISMS. ISO/IEC 27001 requires an organisation to treat its information security risks, and its Annex A includes controls on supplier relationships. ISO/IEC 27002:2022 explains those controls (numbered 5.19 to 5.23, covering supplier relationships in general, security in supplier agreements, the ICT supply chain, monitoring and change of supplier services, and use of cloud services). Organisations commonly use the 27036 series as the detailed method for implementing those controls. A certification auditor then checks the controls, and the 27036-based process provides the evidence.
As a conformity reference. Because Part 2 is written as requirements, an organisation can assess itself against it, or an acquirer can require a supplier to conform and check it.
As contract content. Acquirers can reference the series in agreements and in supplier codes of conduct, and suppliers can describe their processes in its terms.

Types of audit

It helps to know the three parties that can perform an assessment. A first-party assessment is done by the organisation on itself, for example an internal audit of the supplier management process. A second-party assessment is done by a customer, or someone acting for it, on a supplier: this is the classic supplier audit. A third-party assessment is done by an independent body such as an accredited certification body or an audit firm issuing an attestation report. Acquirers combine these: they rely on a supplier's third-party certificate or report where it is relevant, and add second-party checks for gaps.

What evidence to ask for

Assurance evidence comes in many forms, and its value depends on what it covers. Common types include a completed security questionnaire; a current ISO/IEC 27001 certificate together with its scope statement and, ideally, the statement of applicability; independent assurance reports such as SOC 2 reports; penetration test summaries; policy documents; evidence of staff training; an incident history; vulnerability disclosure and patching commitments; and, for software, a software bill of materials (SBOM), which lists the components inside a product. For hardware, provenance records and authorised-channel purchasing help show that parts are genuine.

Two checks matter for any piece of evidence. Does its scope cover the service, the sites and the people that will actually handle your information? And is it current? A certificate for a different business unit, or a report that expired eighteen months ago, provides little assurance.

What an auditor looks for in your process

When an internal or certification auditor examines your supplier security process, they usually want to see that you know your suppliers (an inventory), that you rated their risk in a consistent way, that security requirements were set before contracts were signed, that agreements contain those requirements, that critical suppliers are reviewed on a schedule with records kept, that incidents and changes were handled, and that ended relationships were closed down securely. Good intentions in a policy are not enough; auditors look for records that show the process actually ran.

Proportionality

No organisation can audit every supplier deeply. The series supports a risk-based approach: assurance effort should follow criticality. That means a lightweight check for a supplier with no access to information or systems, a structured evidence review for a moderately important one, and deep assessment, contractual audit rights and regular reviews for the critical few.

Lesson 6 – Worked example: Northbridge Insurance outsources claims handling

Northbridge Insurance is a fictional mid-sized insurer with about 1,200 staff. It holds an ISO/IEC 27001 certificate and is subject to financial sector rules on ICT third-party risk. It decides to replace its in-house claims system with a software-as-a-service (SaaS) claims platform from a specialist vendor, which we will call ClaimsCloud. This example follows the relationship through the lifecycle and shows how the series is applied.

Setting up the organisation-level basics

Before this project, Northbridge's supplier security was informal: procurement held contracts, IT held a list of vendors, and nobody owned the whole picture. The chief information security officer used Part 1 to brief the executive committee on why supplier risk matters, then used Part 2 to design an organisation-wide process. Northbridge wrote a supplier security policy, assigned a business owner to every supplier, created one inventory joining the procurement and IT lists (412 suppliers), and agreed a simple criticality method.

Figure 5 – Northbridge's criticality triage: two questions decide how much assurance each supplier receives and how often it is reviewed.

Applying the triage showed that only 23 suppliers were critical, about 70 were high and the rest were standard. That made the workload manageable and gave a clear order of work: critical suppliers first.

Planning the ClaimsCloud relationship

The claims platform would hold personal and health-related data about policyholders, connect to Northbridge's payment systems and be very hard to replace quickly, so the relationship was rated critical. The project team, with security and legal, wrote down the information involved, its classification and the main risks: a data breach at the vendor, unauthorised vendor access to Northbridge systems, outage of the platform, data stored in an unsuitable jurisdiction, and lock-in. From these they derived requirements: encryption in transit and at rest, single sign-on with Northbridge's identity provider, data held in approved regions, 24-hour incident notification, quarterly vulnerability reporting, an annual independent assurance report, named subcontractors with flow-down of the same duties, and a documented exit with full data export.

Selecting the supplier

Three vendors received the requirements in the request for proposal. Each completed a questionnaire and provided its ISO/IEC 27001 certificate and its latest independent assurance report. The security analyst checked scope first. Vendor A's certificate covered only its sales office, not the platform operations, which was a serious gap. Vendor B could not say which subcontractor provided its overnight support. ClaimsCloud's certificate covered platform operations; it named its cloud hosting provider and its support subcontractor and showed how it reviewed them; and it supplied an SBOM summary for its application with a description of how it tracks vulnerable components. ClaimsCloud was selected, with two findings to close: its incident notification target was 72 hours, and its data export format was proprietary.

Agreeing the terms

Legal used Northbridge's new standard security schedule for critical suppliers. The parties agreed 24-hour notification for incidents affecting Northbridge data, an open export format, audit rights (exercised through the annual independent report plus one on-site review in the first year), notice of new subcontractors with a right to object, data location limits, and an exit plan with six months of transition support. A shared responsibility table, inspired by the cloud guidance in Part 4, recorded what ClaimsCloud protects (platform, infrastructure, application code) and what Northbridge must do itself (user provisioning, access reviews, configuring roles, protecting its own endpoints).

Managing the relationship

Ten months after go-live, ClaimsCloud announced that it would move document scanning to a new subcontractor. Because the agreement required notice, Northbridge learned about it before it happened. The business owner treated the announcement as a change: security reviewed the new subcontractor's location and controls, confirmed that the flow-down clauses applied, and accepted the change with one extra condition on data retention. Later in the year a vulnerability in a widely used software library made headlines. Northbridge asked ClaimsCloud whether the platform was affected; thanks to its component tracking, the vendor answered within hours and patched within two days. The annual review combined the assurance report, the incident log and the change record into one short risk statement for the board.

Planning for termination

Northbridge tested the exit plan once, on paper. The team checked that it could export a full data set in the open format, that it knew which accounts and connections to revoke, and that the vendor would confirm deletion of remaining copies in writing. The exercise found that the payment-system connection used a certificate that nobody had recorded, so it was added to the asset list. If the relationship ends, Northbridge now knows exactly what to do.

What the example shows

The series did not tell Northbridge which vendor to choose or what clauses to write word for word. It gave a structure: organisation-level processes so that every relationship is handled consistently, a lifecycle so that security is present before, during and after the contract, and specific guidance for software supply chains and cloud services. The result was evidence that Northbridge's ISO/IEC 27001 auditor could follow and that its regulator would recognise.

Lesson 7 – Relationship to other standards and frameworks

The series is one part of a larger landscape. Knowing the neighbours helps you decide what to use for which question and avoid duplicated work.

Standard or framework	Owner	Focus	How it relates to ISO/IEC 27036
ISO/IEC 27001	ISO/IEC JTC 1/SC 27	Requirements for an information security management system; certifiable	Provides the management system and the supplier controls in Annex A; 27036 gives the detailed method for those controls
ISO/IEC 27002	ISO/IEC JTC 1/SC 27	Guidance on information security controls, including supplier controls 5.19 to 5.23	Explains the controls briefly; 27036 expands them into processes and supply-chain guidance
ISO/IEC 27017	ISO/IEC JTC 1/SC 27 with ITU-T	Information security controls for cloud services, for providers and customers	Covers how cloud security is implemented; Part 4 covers the customer-provider relationship
ISO/IEC/IEEE 15288 and 12207	ISO/IEC JTC 1/SC 7 with IEEE	System and software lifecycle processes	Part 2 borrows their process groups; Part 3 builds supply-chain security into their processes
NIST SP 800-161 Rev. 1	US NIST	Cybersecurity supply chain risk management (C-SCRM) for systems and organisations	Free, very detailed US guidance with a similar goal; many organisations use both side by side
NIST Cybersecurity Framework 2.0	US NIST	High-level outcomes for managing cybersecurity risk; Govern function includes supply chain risk management	States the outcomes; 27036 supplies a process to achieve the supply-chain ones
ISO 28000	ISO/TC 292	Security management systems for organisations, often applied to supply chain and logistics security	Broader physical and operational supply-chain security; 27036 concentrates on information and ICT

Working with ISO/IEC 27001

The most common pairing is with ISO/IEC 27001. An organisation identifies supplier risks during its ISMS risk assessment, selects supplier controls in its statement of applicability, and uses the 27036 lifecycle to implement them. That way supplier security is not a separate programme but part of the same risk-based system, with the same management review, internal audit and continual improvement.

Working with NIST guidance

NIST SP 800-161 Rev. 1 is free and extremely detailed, with a layered approach covering the enterprise, mission and business process, and operational levels and many specific controls. The NIST Cybersecurity Framework 2.0 added a supply chain risk management category to its Govern function. Organisations that report against the NIST framework can use the 27036 process to produce the outcomes it describes; organisations that prefer international standards can use NIST material as a rich source of ideas. The two are complementary rather than competing.

Software supply chain practices

Since the 27036 parts were written, the industry has developed more specific software supply chain practices: SBOMs in formats such as SPDX and CycloneDX, secure software development frameworks such as the NIST SSDF, build integrity frameworks, and open-source compliance programmes such as OpenChain (published as ISO/IEC 5230 and ISO/IEC 18974). These fit naturally into the guidance of Part 3: they are concrete ways to gain visibility into components and to show acquirers that a supplier manages its upstream chain.

Sector regulation

Regulations increasingly expect supplier security. The EU NIS2 Directive lists supply chain security among the measures essential and important entities must take, and DORA sets detailed rules on ICT third-party risk for financial entities. The series does not guarantee compliance with any regulation, but its processes map well onto what these rules ask for: an inventory, risk assessment, contractual terms, monitoring and exit strategies.

Common pitfalls and best practices

Pitfalls

Onboarding-only security. Assessing a supplier once and never again. Suppliers change owners, subcontractors and systems, and those changes go unnoticed until something breaks.
Accepting certificates at face value. Filing a supplier's ISO/IEC 27001 certificate without checking that its scope covers the service and sites that matter, or that it is still valid.
One questionnaire for everyone. Sending the same long questionnaire to every supplier, which wastes effort on low-risk suppliers and gives too little depth for critical ones.
Security added after the contract. Bringing security in after the supplier is chosen and the price agreed, when there is no leverage left to add requirements.
Ignoring the deeper tiers. Managing direct suppliers carefully while having no idea which subcontractors or components sit behind them.
No exit plan. Discovering at the end of a relationship that data cannot be exported, that nobody knows which accounts exist, or that no replacement can be ready in time.
Treating the series as a certificate target. Spending energy on claiming a "27036 certification" instead of building a working process that produces evidence.

Best practices

Start with an inventory. You cannot manage suppliers you do not know about; join procurement, finance and IT records into one list with a named owner for each supplier.
Tier by criticality. Use a simple, documented method to rate suppliers and scale assurance accordingly, starting with the critical few.
Define requirements early. Put security requirements in the request for proposal and evaluate them alongside cost and features.
Use standard clauses. Maintain a security schedule for contracts, with incident notification times, audit rights, subcontracting rules and exit terms, adapted by criticality.
Manage change actively. Require suppliers to notify significant changes and treat each one as a trigger for risk review.
Ask for component transparency. For software and hardware, ask suppliers how they track components, handle vulnerabilities and verify provenance.
Clarify shared responsibilities. Especially for cloud services, write down which controls the provider operates and which stay with you.
Rehearse the exit. Test exit plans for critical suppliers before you need them.

Summary and key takeaways

The ISO/IEC 27036 series helps organisations protect information in supplier relationships from both the acquirer's and the supplier's point of view; outsourcing work never outsources accountability.
The current parts are Part 1:2021 (overview and concepts), Part 2:2022 (requirements), Part 3:2023 (hardware, software and services supply chain guidance) and Part 4:2016 (cloud services guidance).
Part 2 is the only part written as requirements and works in two layers: organisation-wide processes and a lifecycle for each supplier relationship instance.
The relationship lifecycle runs from planning through selection, agreement and management to termination, and security work is needed at every step.
Visibility shrinks with each tier of a supply chain; acquirers use agreements and flow-down, and suppliers manage their own upstream chain transparently.
There is no widely recognised certificate for the series itself; it is usually applied inside an ISO/IEC 27001 ISMS, as a conformity reference or as contract content.
Assurance effort should follow criticality, and every piece of evidence must be checked for scope and currency.
The series complements ISO/IEC 27001 and 27002, ISO/IEC 27017, NIST SP 800-161, the NIST Cybersecurity Framework and modern software supply chain practices.

Reflection questions

List five suppliers your organisation depends on. For each, which information, systems or premises can it reach, and how critical would you rate it using a triage like Figure 5?
Pick one critical supplier. At which lifecycle step is the relationship now, and what security evidence exists for the steps already completed?
Think of a product or service you buy that contains components from other organisations. How far down its supply chain can you see today, and what would you ask the supplier to improve that visibility?
If your most important cloud provider ended its service with three months' notice, what would you do in the first week? What does your answer tell you about your exit planning?
If you work for a supplier, how would you organise your answers to customers' security questions so that they are consistent, current and based on the lifecycle described here?