Identify who acquires and supplies what, how information and systems are exposed, and where upstream or downstream dependencies change risk.
Use Part 2 for supplier and relationship requirements and Parts 1, 3, and 4 for concepts or guidance. The series is voluntary; assess contracts, law, customer commitments, and certification scopes separately.
Classify the relationship by what is acquired, how the supplier or product can affect information and systems, and where upstream dependencies sit. An procures a product or service; a supplier enters an agreement to provide it. Procurement need not involve payment, the parties can belong to the same organization, and one organization can be an acquirer upstream and a supplier downstream.
Identify the exact product or service, the parties to the agreement, the business purpose, information and systems involved, access and location, term, support model, and direct and indirect dependencies. Do not classify by the supplier's marketing label alone: one agreement can include a product, managed service, cloud service, maintenance, and upstream ICT components with different risks.
ISO/IEC 27036-1 distinguishes product relationships, service relationships, ICT supply chains, and cloud computing contexts. These are practical lenses rather than exclusive legal categories. Apply every relevant lens and use Part 2 for relationship requirements, Part 3 for multi-layer hardware, software, and service supply-chain guidance, and Part 4 for cloud-specific guidance.
Sources (3)
Official ISO catalogue entry for supplier-relationship overview and concepts.
Official ISO catalogue entry for multi-layer ICT supply-chain guidance.
Official ISO catalogue entry for cloud-service supplier relationship guidance; confirmed in 2022.
The type changes the questions and evidence, not whether risk management is needed. A purchased appliance can create supply-chain, vulnerability, update, and maintenance-access risks. A cleaning or facilities service may have little digital access but still have physical access. A software-as-a-service relationship combines service, cloud, software supply-chain, identity, data-location, availability, and exit concerns.
Assess both parties. A supplier can expose the 's information or operations; an acquirer can expose supplier information when it audits production, receives sensitive assurance evidence, or accesses supplier systems. The agreement should allocate responsibilities and protect information in both directions.
Sources (3)
Official ISO catalogue entry for supplier-relationship overview and concepts.
Official ISO catalogue entry for multi-layer ICT supply-chain guidance.
Official ISO catalogue entry for cloud-service supplier relationship guidance; confirmed in 2022.
The inventory should identify the and supplier legal entities, internal relationship owner, product and service components, information and system access, locations, upstream dependencies, criticality, agreement, start and end dates, and classification rationale. If one supplier provides several materially different services, preserve service-level scope rather than assigning one undifferentiated rating.
Link the classification to the assessment, selected ISO/IEC 27036 parts, due diligence, agreement requirements, control owners, operating evidence, review interval, change triggers, and exit plan. Record uncertainties, such as an undisclosed upstream provider or a standard term that can change unilaterally.
A certificate or assurance report supports only the entity, service, locations, controls, and period in its scope. Record the reviewer conclusion and any relationship risk it does not address.
Sources (3)
Official ISO catalogue entry for supplier-relationship overview and concepts.
Official ISO catalogue entry for multi-layer ICT supply-chain guidance.
Official ISO catalogue entry for cloud-service supplier relationship guidance; confirmed in 2022.
Identify the parties, acquired product or service, information and access exposure, dependencies, and relevant parts of the series.
Reclassify when the product becomes connected, the supplier gains support access, the service begins handling new information, hosting or production moves, a new cloud or upstream provider is introduced, standard terms change, or support ends. Also revisit the classification after ownership changes, serious incidents, control failures, renewal, or a change in business criticality.
A type change can require new controls or evidence even if the supplier and contract name stay the same. Record the effective date, changed assumptions, reassessment, agreement impact, and approval.
At termination, apply the exit actions for every active lens: product replacement and support removal, service and privileged-access closure, cloud data export and disposal, and treatment of remaining upstream dependencies.
Sources (3)
Official ISO catalogue entry for supplier-relationship overview and concepts.
Official ISO catalogue entry for multi-layer ICT supply-chain guidance.
Official ISO catalogue entry for cloud-service supplier relationship guidance; confirmed in 2022.
Build ISO/IEC 27036-aligned supplier security clauses from relationship risk, responsibilities, assurance, change, incidents, and exit.
Apply ISO/IEC 27036 across ICT supply-chain planning, acquisition, delivery, operation, change, and disposal.
Manage indirect supplier dependencies under ISO/IEC 27036 using risk-based visibility, flow-down expectations, monitoring, and contingency planning.
Run ISO/IEC 27036 supplier onboarding and offboarding with approval gates, evidence, access control, continuity, and verified closure.
Design risk-based ISO/IEC 27036 supplier assurance with defined evidence scope, monitoring, findings, and reassessment.
Build ISO/IEC 27036 supplier monitoring that turns agreed measures, assurance, incidents, changes, and findings into decisions.
Plain-language answers about ISO/IEC 27036 scope, parts, roles, agreements, assurance, monitoring, incidents, indirect suppliers, cloud services, and exit.
Use an ISO/IEC 27036 supplier-risk checklist across scope, assessment, agreement, operation, change, incidents, and termination.
Compare ISO/IEC 27036 supplier-relationship security with NIST SP 800-161 Rev. 1 cyber supply-chain risk management.
Understand how to apply the four-part ISO/IEC 27036 series without treating it as a law or standalone certification.
Collect evidence that answers a defined relationship-risk or agreement question and matches the product or service, period, location, controls, and dependencies in scope. A certificate, audit report, questionnaire, or attestation is an input, not automatic proof.
Treat cloud as a supplier relationship with cloud service customer and provider perspectives. Apply Part 2 relationship requirements and Part 4 cloud guidance, then document how responsibility changes with the service and deployment model, configuration, data, interfaces, and nested cloud services.
Include controls selected from the relationship risk treatment and responsibilities, not a generic clause library. The agreement should make scope, performance, evidence, communication, exceptions, change, incident coordination, continuity, and exit reviewable by both parties.
Use the direct supplier relationship to obtain proportionate visibility and assurance over upstream dependencies that can materially affect security or delivery. ISO/IEC 27036 describes multi-layer supply chains; it does not require the same questionnaire or direct audit right for every remote tier.
No fixed low, medium, or high tier model is prescribed by ISO/IEC 27036. Organizations can use tiers to scale due diligence, agreement terms, assurance, monitoring, approvals, and exit planning, but the criteria and decisions must reflect their own context and risk appetite.
Agree supplier incident triggers, immediate reporting, investigation, recovery, and closure. Derive specific notification deadlines from applicable law or contract.
ISO/IEC 27036 does not prescribe one universal monitoring interval. Set scheduled and event-driven reviews according to risk, agreement terms, service criticality, evidence availability, and the speed at which the relationship can change.
Plan termination before the relationship starts. Coordinate continuity and transition, revoke physical and logical access, rotate shared secrets, disable integrations, recover assets, return or delete information subject to retention duties, preserve required records, and verify surviving obligations.