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 acquirer 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.
Structured answer sets in this page tree.
Cited legal and guidance references.
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.
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.
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.
Capture owners, evidence, decisions, and review dates in one workflow record so supplier security controls and escalation points stay auditable over time.
Convert ISO/IEC 27036 Supplier Relationship Types into accountable tasks, evidence requests, and review checkpoints.
Review your current scope, evidence gaps, and next implementation steps.
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.