Search every question across sub-FAQs

Collect assurance 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.

ISO/IEC 27036-2:2022 sets requirements for acquirers and suppliers across the relationship lifecycle. It identifies several forms of assurance, including performance reports, attestations, self-assessments, independent assessments, audits, tested continuity plans, and ISO/IEC 27001 certification. Part 3:2023 adds hardware, software, and service supply-chain guidance. The acquirer must decide what evidence is credible and sufficient for the selected supplier and requirement.

Use a certificate to confirm only the certified management-system scope and period. Use an independent audit or attestation report for the controls, system boundary, period, exceptions, and complementary responsibilities it actually covers. Use questionnaires and interviews to fill relationship-specific gaps, but verify consequential answers with records, demonstrations, tests, or other independent evidence when the risk warrants it.

Product evidence can differ from organization-level evidence. For hardware, software, and services, relevant evidence may include test results, vulnerability and remediation records, chain-of-custody records, provenance information, a software bill of materials, delivery verification, or proof that required security features work. A software bill of materials helps identify components and relationships, but it does not prove that the listed components are vulnerability-free or securely configured.

Retain the relationship and requirement being assessed, the evidence requested and received, its scope and period, the reviewer, the conclusion against stated acceptance criteria, open findings, corrective-action owner and due date, residual-risk decision, approval, and next review or event trigger.

Reassess when evidence expires or the service, product, location, ownership, subcontracting, threat exposure, agreement, or intended use changes. An incident or material control failure can require an earlier review.

Treat cloud as a supplier relationship with cloud service customer and cloud service provider perspectives. Apply ISO/IEC 27036-2:2022 relationship requirements and ISO/IEC 27036-4:2016 cloud guidance, then document how responsibility changes with the service and deployment model, configuration, data, interfaces, and nested cloud services. Part 4 is guidance and does not replace cloud-specific law, regulation, sector rules, or contractual duties.

The provider's controls do not remove the customer's responsibilities. For the actual service, record who manages identities, privileged access, configuration, logging, encryption, backups, vulnerability response, incident communication, and data return or disposal. Check legal and contractual duties separately.

Review the service description, responsibility model, standard terms, service levels, data and administrative paths, provider locations, subprocessors or nested cloud services, change-notice process, available logs, assurance scope, backup and recovery capabilities, incident support, portability, and termination process.

Acceptance evidence should relate to the subscribed service and configuration. Organization-wide certification can support the decision, but it does not by itself show that the selected service, region, controls, or customer configuration meets the requirement. Public, hybrid, and private deployment labels do not settle the risk: information importance, customer control, location, privileged access, separation, logging, portability, and the actual allocation of responsibility still matter.

Monitor service and provider changes against the agreed responsibility map and risk decision. Define which changes require notice, review, approval, reconfiguration, or migration. The customer and provider should also agree incident contacts and the information needed for impact assessment and response.

Before termination, export and verify required information, transfer service where needed, revoke access and integrations, and obtain the agreed evidence of disposal. Part 4 addresses cloud information return and disposal, but it does not itself provide business-continuity management guidance; use the agreement, applicable obligations, and relevant continuity standards for that work.

Include controls selected from the relationship risk treatment and responsibilities, not a generic clause library. The supplier relationship agreement should make scope, performance, evidence, communication, exceptions, change, incident coordination, and exit reviewable by both parties.

ISO/IEC 27036-2 requires the agreement process to address information-security roles, controls across information, ICT, personnel, and physical security, transition, change, incidents, compliance monitoring and enforcement, and termination. The exact clauses still depend on the product or service, risk treatment, negotiation model, and applicable law.

A clause should say enough for both parties to act and for a reviewer to test performance. For incident reporting, define the trigger, contact path, required initial facts, update expectations, evidence preservation, investigation support, and any deadline supplied by law or contract. ISO/IEC 27036-2 requires an agreed incident-management procedure and immediate reporting within that procedure, but it does not supply a universal number of hours. For changes, define which service, location, ownership, control, subcontractor, or technology changes require notice or approval.

For assurance and enforcement, define the reports, attestations, self-assessments, independent assessments, audit access, correction process, and consequences that apply. For termination, define transfer or cancellation, asset inventory, access removal, return, retention or destruction, communication, transition support, and completion evidence.

A click-through, licence, public-cloud, or other standard-form agreement can still create a supplier relationship. If the supplier will not change its terms, compare the available commitment and evidence with the requirement, record each material gap, and decide whether configuration, architecture, reduced scope, insurance, monitoring, redundancy, or another compensating control brings risk within the organization's acceptance criteria.

If the remaining risk is outside those criteria, send the decision to the authorized risk owner. Do not label the relationship compliant merely because the terms are common in the market.

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 a multi-layer supply chain; it does not require the same questionnaire or direct audit right for every remote tier.

ISO/IEC 27036 uses supply-chain and subcontractor language rather than defining "fourth party." On this page, fourth party means a supplier, component source, service, or other dependency used behind the direct supplier. The direct supplier remains the practical route for setting upstream requirements unless another agreement gives the acquirer direct rights. A subcontractor is not automatically high risk, and a non-contractual component or open-source dependency can still be consequential.

Go as far as the relationship risk and available influence justify. Start with the function and exposure, not a fixed number of tiers. A remote supplier can deserve attention when it controls a critical component, processes sensitive information, has privileged access, is a single source, or creates a shared dependency across several direct suppliers.

For lower-impact dependencies, evidence that the direct supplier operates an effective upstream risk process may be enough. For a critical dependency, ask for the identity or category, function, location, change and incident duties, assurance evidence, alternatives, and recovery or substitution plan. If identity cannot be disclosed, record the visibility limit and assess whether other evidence or controls are sufficient.

Limited visibility leaves the dependency's security unproven. Record what is unknown, why it matters, which direct-supplier evidence was reviewed, and which controls reduce the exposure. Options can include segmentation, least privilege, data minimization, verified updates, inventory and provenance records, diverse supply, substitution, monitoring, or explicit residual-risk acceptance.

Do not promise direct audit rights over an upstream supplier unless an agreement grants them. ISO/IEC 27036 supports proportionate visibility and recursive requirements; it does not create contractual privity or a universal right to inspect every 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.

ISO/IEC 27036-2:2022 requires the acquirer's risk assessment to be commensurate with the criticality of the product or service and requires an acceptable risk level and treatment plan. A tier is an internal way to apply those decisions consistently; it is not an ISO classification or certificate and does not replace the relationship-specific assessment.

Define each factor, data source, scoring or decision rule, override, approver, and resulting treatment before applying labels. Keep impact separate from control evidence: a critical supplier does not become low impact because it has strong assurance, and weak evidence does not by itself describe the business consequence of failure. Calculate or decide inherent risk first, evaluate controls and evidence, then record residual risk and the resulting tier or treatment.

Allow an override when one fact dominates the result, such as unrestricted production access, regulated data, a single-source critical component, or an exit time longer than the business can tolerate. Record the reason instead of changing inputs to force the expected tier.

Reassess when the product or service scope, information, access, integration, location, supplier ownership or financial condition, subcontractors, concentration, support status, threat exposure, agreement, law, or business criticality changes. Incidents, repeated findings, missed corrective actions, and failed recovery or exit tests are also useful triggers.

Keep the prior tier, evidence, rationale, approver, effective date, treatment changes, and next review. If the tier remains unchanged after a material event, record why the existing treatment is still sufficient.