Framework

ISO/IEC 27036
supplier-relationship security lifecycle

ISO/IEC 27036 (Cybersecurity for supplier relationships) is the international standard for information security in supplier relationships. The four parts cover the supplier-relationship vocabulary, the normative requirements across the lifecycle (planning, supplier selection, agreement establishment, agreement management, agreement termination, post-agreement disposal), the ICT supply chain extension, and the cloud-services extension. This page covers the four parts, the six lifecycle phases, the supplier categorisation patterns, the minimum agreement clause set, the acquirer-side evidence pack, the operating cadence, the failure modes, and the cross-walk to NIST SP 800-161, DORA Article 28, NIS2 Article 21(2)(d), SOC 2 CC9.2, HIPAA BAA, the EU Cyber Resilience Act, CSA STAR, ISO/IEC 27017, and ISO/IEC 27001 Annex A 5.19 to 5.23.

Get Started Free

No credit card required. Free plan available forever.

ISO/IEC 27036 explained for enterprise teams

ISO/IEC 27036 (Cybersecurity for supplier relationships) is the international standard for information security in supplier relationships. It is the operating reference programmes reach for when they need to evidence supplier-side security across the supplier-relationship lifecycle: planning, supplier selection, agreement establishment, agreement management, agreement termination, and post-agreement disposal. The standard is published in four parts across IEC, ISO, and the related ITU-T technical guidance, and reads alongside ISO/IEC 27001 Annex A 5.19 to 5.23 (information security in supplier relationships) as the deeper implementation companion.

For internal security teams, GRC and compliance teams, vendor risk leads, AppSec teams managing third-party components, cloud security teams managing SaaS and IaaS providers, procurement teams running supplier onboarding, legal teams negotiating contract clauses, and CISOs accountable for supply-chain risk, ISO/IEC 27036 is the standard the supplier programme reads against globally. The framework is dense; the value is the lifecycle discipline that turns supplier security from a one-off due-diligence step into a continuous operating record.

This page covers the four parts of the standard, the six lifecycle phases, the supplier categorisation patterns, the minimum agreement clause set, the acquirer-side evidence pack, the operating cadence, the failure modes that erode the supplier programme, and where ISO/IEC 27036 sits alongside NIST SP 800-161r1, DORA Article 28, NIS2 Article 21(2)(d), the EU Cyber Resilience Act, and CSA STAR. Programmes that adopt ISO/IEC 27036 as the supplier-relationship operating standard read cleanly into every adjacent regime without rebuilding the evidence pack per audit.

The four parts of ISO/IEC 27036

ISO/IEC 27036 is published in four parts. Only Part 2 is normative; the other three are guidance that explains how to operate Part 2 in context. The structure lets a programme certify or declare conformity against Part 2 while reading Parts 1, 3, and 4 as the implementation companion for orientation, ICT supply chain, and cloud-service relationships respectively.

ISO/IEC 27036-1: Overview and concepts

The orientation part. Defines the supplier-relationship vocabulary the rest of the standard reads against (acquirer, supplier, supplier relationship lifecycle, supplier categorisation, information security risks in supplier relationships) and names how 27036 sits alongside ISO/IEC 27001, ISO/IEC 27002, the wider ISO 27000 family, and the procurement and contract management disciplines. Part 1 is the part newcomers read first; experienced programmes read it once and treat it as the glossary the operating parts inherit from.

ISO/IEC 27036-2: Requirements

The requirements part. Lists the requirements an acquirer and a supplier each carry across the supplier relationship lifecycle: planning, supplier selection, agreement establishment, agreement management, agreement termination, and post-agreement disposal. Part 2 is the only normative part of the standard. An organisation declaring conformity to ISO/IEC 27036 is declaring conformity to Part 2. The other parts are guidance that explains how to operate the Part 2 requirements in context.

ISO/IEC 27036-3: Guidelines for ICT supply chain security

The ICT supply chain part. Adds the supply-chain context to the supplier-relationship requirements: hardware, software, and service supply chains in particular, the tiered supplier model (Tier 1 direct suppliers, Tier 2 sub-suppliers, Tier 3 and beyond), supply chain traceability, integrity of components in transit and at handoff, and the inheritance of obligations down the supplier chain. Part 3 reads alongside NIST SP 800-161 for the federal-grade C-SCRM context and alongside the EU Cyber Resilience Act for the product-side supply-chain expectations.

ISO/IEC 27036-4: Guidelines for security of cloud services

The cloud-services part. Tailors the supplier-relationship requirements to cloud service consumption: cloud customer and cloud service provider as the acquirer and supplier in cloud terms, the shared responsibility model, the cloud-specific information security risks, the cloud agreement clauses (location of processing, sub-processor management, exit and portability, incident notification), and the cloud-specific monitoring and assurance reads. Part 4 sits alongside ISO/IEC 27017 (cloud security controls) and ISO/IEC 27018 (PII in public cloud).

The six lifecycle phases

ISO/IEC 27036 is a lifecycle standard. The requirements in Part 2 are organised by the phases the supplier relationship moves through over time. The phases below are the spine the operating record reads against. Programmes that operate the lifecycle as one continuous record (rather than six separate projects) carry the supplier programme cleanly through renewal cycles, audit cycles, and regulator cycles.

  1. 1

    Planning

    Define the requirement the supplier will satisfy, the information security risks the relationship will carry, the supplier categorisation (commodity vs strategic, low-risk vs high-risk, single-source vs multi-source), the assessment depth required per category, and the contract templates the relationship will be governed under. Planning is the cheapest phase to invest in and the most expensive to skip: gaps named here propagate through every later phase.

  2. 2

    Supplier selection

    Run the supplier security due diligence appropriate to the category named at planning. The due-diligence pack typically includes the supplier questionnaire (SIG, CAIQ, or programme-specific), the published assurance evidence (ISO/IEC 27001 certificate, SOC 2 Type II report, STAR Registry entry, FedRAMP authorisation), the technical and process maturity assessment, the financial stability check, the geographic and regulatory exposure check, and the reference check. The selection record documents the rationale and the residual concerns.

  3. 3

    Agreement establishment

    Convert the security requirements into binding contract clauses. The minimum clause set covers data handling and classification, sub-processor management with prior approval where applicable, security controls expectation by reference to the wider regime (ISO/IEC 27001 Annex A 5.19 to 5.23, NIST SP 800-53 SR family, CSA CCM where cloud), audit and assurance rights, vulnerability and incident notification timing (often 24 to 72 hours), data return and destruction at termination, business continuity and disaster recovery expectations, personnel security, encryption-at-rest and in-transit, and the indemnities and limitations that anchor the commercial side. Agreement establishment is when ISO/IEC 27036-2 Part 2 requirements become legally binding.

  4. 4

    Agreement management

    Operate the relationship after signature. Agreement management is the longest phase by far. It covers the periodic supplier assessment cadence (annual for high-risk, biennial for medium-risk, on-event-or-renewal for low-risk), the supplier KPI tracking, the incident-notification handling, the vulnerability-notification handling, the change-management coordination (supplier-side changes that affect the acquirer-side risk position), the sub-processor change handling, the assurance-evidence refresh tracking, the contract amendment cycle, and the renewal decision lead-time. Most ISO/IEC 27036 evidence the auditor reads sits in agreement management.

  5. 5

    Agreement termination

    Wind down the relationship in line with the termination clauses. Termination is where the agreement-management discipline either pays back or shows the gap: data return on documented timelines, data destruction with attestation, sub-processor termination cascade, access revocation, transition-out support, knowledge transfer, asset return, and final assurance evidence. Programmes that treat termination as an afterthought rebuild this section under pressure on every relationship that ends.

  6. 6

    Post-agreement disposal

    Confirm that the disposal expectations from termination were met, retain the residual evidence the auditor will read (the destruction attestation, the final assurance evidence, the closure record), and feed the supplier-experience lessons back into the planning artefacts for future relationships. Post-agreement disposal is the closing-out artefact ISO/IEC 27036 expects to exist. It also feeds the supplier-relationship maturity loop programmes use to improve subsequent contracts.

Supplier categorisation patterns

ISO/IEC 27036 expects the supplier set to be categorised so the assessment cadence, the contract templates, and the operating intensity match the risk per relationship. The categorisation patterns below are the dimensions the standard names and that mature programmes typically combine into a per-supplier category that the operating cycle reads against. Single-dimension categorisation under-weights the relationships that look low risk on one axis and high risk on another.

  • Commodity vs strategic. Commodity suppliers carry interchangeable services with thin switching cost; the assurance posture is lighter and the contract templates are more standardised. Strategic suppliers carry harder-to-replace dependencies; the assurance posture is heavier and the contract terms are negotiated. Programmes that apply the same security depth to both end up over-investing in commodity and under-investing in strategic.
  • Single-source vs multi-source. Single-source dependencies (one supplier per service) carry concentration risk that must be reflected in the BCDR plan and the exit plan. Multi-source dependencies carry orchestration risk but reduce the concentration. ISO/IEC 27036 expects the source posture to be a documented decision rather than an emergent state.
  • Direct vs sub-supplier (Tier 1, Tier 2, Tier 3). The acquirer typically has direct visibility into Tier 1 suppliers and inherited visibility into Tier 2 and beyond through Tier 1 contract clauses. Part 3 covers the inheritance model in detail. Programmes that treat the sub-supplier chain as out of scope fail under the NIS2, DORA, and CRA reads where regulators ask for the full chain.
  • Low-risk vs high-risk by data classification. Suppliers handling regulated, sensitive, or material information carry a deeper assurance posture than suppliers handling commercial or low-classification information. The data-classification policy and the supplier-categorisation policy read into each other; ISO/IEC 27036 expects the classification-to-supplier-tier mapping to be documented and applied.
  • Onshore vs offshore vs cross-border. Geographic dispersion changes the regulatory exposure (data protection regimes, sectoral regulators, sanctions regimes, transfer mechanisms). Suppliers in different jurisdictions trigger different contract terms (standard contractual clauses for cross-border personal data, transfer impact assessments, sub-processor location restrictions, sovereign cloud requirements).
  • New vs incumbent. New supplier relationships carry a different assurance load than renewing relationships. Incumbents have an operating history (incidents, performance, contract amendments) the assessment can read against. New suppliers carry only published assurance and reference checks until the relationship establishes its own history. Programmes treat the two with appropriately different cadences.

The minimum agreement clause set

ISO/IEC 27036-2 expects the security expectations to land in the contract. The minimum clause set below covers the requirements Part 2 reads against and the related downstream obligations the acquirer needs to meet (regulator notification clocks, audit-evidence retention, sub-processor handling, termination assistance). Programmes drafting supplier contracts use this set as the structural minimum and tailor the depth per supplier category.

  • Information security controls clause. Names the security expectations by reference to a recognised regime: ISO/IEC 27001 Annex A controls, NIST SP 800-53 family controls, CSA CCM domains, sector-specific control sets, or the acquirer-specific control list. The clause carries the assurance evidence requirement (ISO/IEC 27001 certificate with current Statement of Applicability, SOC 2 Type II report with current period, STAR Registry entry with current validity, sector certification with current date).
  • Data handling and classification clause. Names what classes of data the supplier processes, the handling expectations per class (access control, encryption, retention, return, destruction), the lawful basis where personal data is processed, and the cross-border transfer mechanism where applicable. The clause carries the documented data flow the acquirer can audit against.
  • Sub-processor management clause. Names the sub-processor approval expectation (prior consent, notification with right to object, change notification cascade), the sub-processor list maintenance, the sub-processor flow-down obligation (the supplier flows the same security obligations down to its sub-processors), and the sub-processor termination cascade.
  • Security incident notification clause. Names the incident notification timing (commonly 24 hours for known compromises, 72 hours for confirmed incidents, immediate for regulated personal data breaches), the notification content (what happened, what data was affected, what response is underway, what the acquirer-side notification obligations look like), and the post-incident reporting timeline. The notification clause is the artefact that lets the acquirer meet its own regulator notification clocks under GDPR Article 33, NIS2 Article 23, DORA Article 19, and sectoral equivalents.
  • Vulnerability notification clause. Names the supplier-side vulnerability disclosure expectation (CVE notification, advisory subscription, security bulletin distribution, exploitability assessment, patch availability and timeline) and the acquirer-side handling expectation. Pairs with ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling) for software-supplier relationships.
  • Audit and assurance rights clause. Names the audit cadence (annual or on event), the audit scope (security controls evidence, sub-processor evidence, incident evidence), the audit method (acquirer-led audit, third-party-led audit, attestation-based audit), the costs allocation, the prior-notice expectation, and the confidentiality envelope. Pairs with the audit-evidence retention clause that names how long evidence is kept readable to the audit.
  • Business continuity and disaster recovery clause. Names the supplier-side BCDR expectations: documented BCDR plan, RTO and RPO commitments per service tier, exercise cadence with after-action evidence, sub-supplier BCDR flow-down, communication during disruption, and the supplier-side reliance on its own suppliers. Pairs with ISO 22301 and ISO/IEC 27031 for the standards-side BCDR reference.
  • Data return and destruction clause. Names the data return timeline at termination (commonly 30 to 90 days), the return format expectation (machine-readable, structured, complete), the destruction timeline after return is complete (commonly 30 to 60 days), the destruction attestation expectation, and the retention exception window where statutory retention applies. The clause is the artefact the audit reads to confirm the post-agreement disposal record matches the contract commitment.
  • Termination assistance clause. Names the transition-out support expectation: continued operation during the transition window, knowledge transfer to the successor supplier or the acquirer in-house team, asset return, access revocation cadence, and the supplier-side reach-back commitment for a defined period after termination for clean-up issues. Programmes that omit this clause discover at termination that the supplier-side cooperation is the bottleneck of the transition.
  • Personnel security clause. Names the supplier-side personnel security expectation: background checks proportionate to the data sensitivity, security training requirements, sub-contractor personnel handling, departure access revocation, and named-personnel handling for highly sensitive contracts (where the contract identifies specific cleared personnel rather than the supplier as a whole).

The acquirer-side evidence pack

The minimum durable evidence pack the auditor, the regulator, and the audit committee each read against the supplier programme is grouped below by artefact type rather than by audit question. Each artefact carries a named owner, a refresh cadence, and a version history so reconstruction at audit time is replaced with a continuous operating trail. ISO/IEC 27036 does not invent these artefacts; it names what the supplier-relationship operating record needs to contain to satisfy the requirements in Part 2.

  • The supplier inventory: a structured queryable record of every supplier in scope, the supplier category (strategic vs commodity, single-source vs multi-source, low-risk vs high-risk by data class, onshore vs offshore), the data classes the supplier processes, the services the supplier provides, the contract reference, the term, the renewal date, the named relationship owner, the named acquirer-side technical lead, and the named acquirer-side legal owner.
  • The supplier risk assessment record: the per-supplier risk position with the inherent risk, the controls evidenced through assurance and due diligence, the residual risk position, the residual risk owner, the residual risk acceptance with named decision-maker, and the reassessment trigger set. The risk assessment is refreshed on the cadence named in planning and on event.
  • The supplier assessment evidence: the questionnaire response with date and version, the published assurance evidence (ISO/IEC 27001 certificate plus current SoA, SOC 2 Type II report plus period, STAR Registry entry plus validity, FedRAMP authorisation plus type and ATO date, sector certification), the on-site or remote assessment record where applicable, the technical assessment record where applicable (pentest, code review, configuration review against the contract baseline), the reference check record, and the assessment-firm independence statement where third-party assessments are relied on.
  • The contract pack: the signed agreement with version history, the amendments and side letters with effective dates, the data processing addenda where applicable, the sub-processor schedule with the current sub-processor list, the standard contractual clauses pack where personal data crosses borders, the transfer impact assessments where applicable, and the executed termination assistance terms.
  • The incident notification log: every incident notification received from the supplier, the timeline against the contract notification clause, the response coordination record, the post-incident analysis, the corrective action commitment, the acquirer-side regulator notification record where downstream notification was required, and the residual position after the corrective action is verified.
  • The vulnerability notification log: every vulnerability notification received, the affected component or service, the supplier-side severity assessment, the acquirer-side severity assessment in context, the patch or mitigation availability and timeline, the deployment record, and the closure record. Pairs with the vulnerability management programme record so vulnerability-handling does not bifurcate into supplier-channel and direct-channel tracks.
  • The audit log: every audit performed against the supplier (acquirer-led, third-party-led, attestation review), the audit scope, the findings, the corrective action plan, the corrective action verification, and the residual issues entering the next cycle. Pairs with the assurance evidence record so the audit reads alongside the published assurance rather than as a separate track.
  • The BCDR evidence: the supplier-side BCDR plan in current version, the exercise after-action evidence from the most recent cycle, the RTO and RPO commitments per service tier, the disruption notification history, and the acquirer-side dependency-mapping record that names which acquirer services depend on which supplier services.
  • The termination record: the termination notice with date, the data return record with timeline, the data destruction attestation with date, the access revocation record with date, the asset return record, the transition-out support record, the closure activity log, and the post-agreement disposal confirmation.
  • The supplier KPI record: the per-supplier service-level performance against the contract, the incident frequency, the vulnerability backlog, the audit finding closure rate, the change-management cooperation, and the renewal recommendation from the relationship owner with the rationale.

A practical operating cadence

The cadence below is the operating rhythm most ISO/IEC 27036 programmes settle into when they treat supplier security as continuous work rather than a contracting moment. The per-quarter rhythm reads against the calendar; the on-event work reads against the operational triggers; the on-termination work reads against the contract lifecycle. The cycle compounds: each year inherits evidence from the prior year, so the supplier programme becomes the durable record audits and regulators read against rather than a separate audit preparation project.

  • Quarter 1 of each year: refresh the supplier inventory against the actual contract pack, reconcile the inventory with finance and procurement records, and refresh the supplier categorisation against any changes in data classes, geographic exposure, or strategic position. The Q1 inventory refresh is the input the rest of the year reads against.
  • Quarter 2 of each year: run the annual assessment cycle against high-risk and strategic suppliers. Refresh the published assurance evidence (ISO/IEC 27001 certificates, SOC 2 Type II reports, STAR Registry entries, FedRAMP authorisations) for every supplier with assurance evidence. File the residual-risk acceptance refresh for any high-risk supplier whose residual position is unchanged.
  • Quarter 3 of each year: run the medium-risk supplier assessment cadence and the BCDR exercise alignment with strategic suppliers. The BCDR exercise alignment confirms the supplier-side BCDR plan reads against the acquirer-side BCDR plan and that the joint exercises are scheduled. The Q3 cycle also covers contract amendment windows for renewals coming up in the following year.
  • Quarter 4 of each year: prepare renewal decisions for contracts expiring in the following year, run the year-end audit-readiness pack assembly against the supplier programme, and refresh the supplier KPI record per relationship. The Q4 audit-readiness pack is the artefact the external audit (ISO/IEC 27001 surveillance, SOC 2 examination, regulator review) reads against in the new year.
  • On event: receive and triage supplier security incident notifications against the acquirer-side regulator notification clocks, receive and triage supplier vulnerability notifications against the acquirer-side patching cycle, process sub-processor change notifications, process supplier ownership change notifications (acquisitions, divestitures), and refresh the affected risk assessments.
  • On termination: execute the termination clauses (data return, data destruction, access revocation, transition-out support), file the post-agreement disposal record, archive the supplier file with the retention policy applied, and feed the supplier-experience lessons back into the planning artefacts for the next supplier cohort.

Failure modes the standard is designed to surface

ISO/IEC 27036 is forgiving on the choice of tooling, the contract templates, and the depth of assessment per supplier. It is unforgiving about a small number of patterns that turn the supplier programme cosmetic rather than operational. The patterns below recur across supplier-relationship security programmes and are the ones that erode the year-over-year continuity that audits, regulators, and audit committees increasingly read against.

  • Treating supplier security as procurement-only. The supplier-relationship requirements span planning, selection, agreement, agreement management, termination, and disposal. Programmes that confine supplier security to the contracting moment build a clause library and miss the per-cycle assessment, the incident-notification handling, the BCDR exercise, and the termination evidence the rest of the standard expects.
  • Treating supplier security as security-only. The mirror failure mode. Security teams that operate ISO/IEC 27036 without procurement, legal, vendor risk, business owners, and finance produce assessment records that procurement does not read and contract clauses that vendor risk does not enforce. The four-corner model (security, procurement, legal, vendor risk) is what the standard expects.
  • Pulling assurance evidence at contract signature and never refreshing. ISO/IEC 27001 certificates expire. SOC 2 Type II reports cover a period. STAR Registry entries have validity windows. FedRAMP authorisations carry continuous-monitoring obligations the acquirer is expected to verify. Programmes that file the assurance evidence at signature and never refresh end up holding a contract supported by expired or out-of-date assurance.
  • Ignoring the sub-supplier chain. The standard explicitly covers Tier 1, Tier 2, and Tier 3 inheritance. Regulators reading the supplier programme increasingly ask for the sub-processor list per supplier and the flow-down evidence. Programmes that hold Tier 1 inventories but no Tier 2 visibility fail under NIS2 Article 21(2)(d), DORA Article 28(2)(c), and the cross-border transfer-impact-assessment reads.
  • Letting the supplier inventory drift. The inventory is the load-bearing artefact the rest of the programme reads against. Inventories maintained as spreadsheets in different teams, refreshed once a year through a survey, and stitched together at audit time drift quickly. The standard expects the inventory to be a structured queryable record with named owners, refresh on event, and a controlled change record.
  • Treating incident notification as a contract clause without an operating loop. The 72-hour notification clause is necessary and not sufficient. The acquirer needs the operating loop that receives the notification, triages it against the acquirer-side regulator notification clocks (GDPR Article 33 in particular), coordinates the response, and closes the loop with the corrective action record. Programmes that have the clause but no loop discover the gap during the first material incident.
  • Confusing supplier categorisation with vendor categorisation. Procurement categorisation often reads against commercial criticality (spend, strategic value). ISO/IEC 27036 categorisation reads against information security risk (data sensitivity, single-source concentration, sub-processor depth, geographic exposure). Programmes that reuse the procurement categorisation as the security categorisation miss the security-side high-risk relationships that are commercially low-spend.
  • Skipping the post-agreement disposal record. Termination is the easy story to tell on paper and the most-skipped artefact in practice. The data return, the destruction attestation, the access revocation, and the closure activity log are the artefacts that come back to bite the programme when the auditor or the regulator asks years later whether the contract closed cleanly.
  • Treating supplier security as a one-off project rather than a continuous discipline. ISO/IEC 27036 is a lifecycle standard. The supplier programme reads against the same operating record on Day 1 of agreement management, in the middle of the contract, on incident notification, on sub-processor change, on renewal, on termination, and on post-agreement disposal. Programmes that treat 27036 as a one-time procurement compliance step file an artefact pack that ages out within the first contract cycle.

How ISO/IEC 27036 relates to adjacent regimes

ISO/IEC 27036 sits in a busy regulatory and standards neighbourhood. The relationships below are the ones programmes encounter most often when they read the standard against the rest of the supplier-security regime. Programmes operating across regions and sectors use ISO/IEC 27036 as the operating spine and read NIST 800-161r1, DORA, NIS2, CRA, SOC 2 CC9.2, HIPAA BAA, CSA STAR, and ISO/IEC 27017 as the framework-specific reads beneath.

ISO/IEC 27036 vs ISO/IEC 27001 Annex A 5.19 to 5.23

ISO/IEC 27001 Annex A 5.19 to 5.23 are the supplier-relationship controls in the certifiable ISMS standard (information security in supplier relationships, addressing security within supplier agreements, ICT supply chain, monitoring and reviewing supplier services, managing change to supplier services). ISO/IEC 27036 is the deeper guidance and requirements set that explains how to operate those controls. Programmes operating both certify against ISO 27001 (and evidence Annex A 5.19 to 5.23) while reading ISO/IEC 27036 as the implementation companion.

ISO/IEC 27036 vs NIST SP 800-161r1

NIST SP 800-161r1 (Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations) is the federal C-SCRM framework with the SR control family in NIST SP 800-53 Rev. 5 underneath. ISO/IEC 27036 is the international supplier-relationship security standard. The two are complementary rather than competing. ISO/IEC 27036 supplies the supplier-relationship vocabulary procurement and vendor risk teams use globally. 800-161r1 supplies the federal-grade C-SCRM strategy and the SR control set. Programmes operating against both use 800-161r1 as the strategy spine and ISO/IEC 27036 as the supplier-relationship companion.

ISO/IEC 27036 vs DORA Article 28

DORA Article 28 imposes detailed third-party ICT risk obligations on EU financial entities: contractual provisions, register of information on contractual arrangements, monitoring and oversight of ICT third-party service providers, and exit strategies. ISO/IEC 27036 reads beneath DORA Article 28 as the operating standard the contract clauses, the assessment cadence, the monitoring discipline, and the exit planning read against. Financial entities subject to DORA build the Register of Information on contractual arrangements against the same supplier inventory ISO/IEC 27036 expects.

ISO/IEC 27036 vs NIS2 Article 21(2)(d)

NIS2 Article 21(2)(d) requires essential and important entities to manage supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. ISO/IEC 27036 reads as the operating standard for the supply chain security requirement. NIS2 expects the direct-supplier focus with the sub-supplier inheritance; Part 3 of ISO/IEC 27036 covers exactly that pattern.

ISO/IEC 27036 vs EU Cyber Resilience Act

The EU Cyber Resilience Act (Regulation 2024/2847) obliges manufacturers placing products with digital elements on the EU market to maintain SBOM, vulnerability handling, and lifecycle security obligations. ISO/IEC 27036 is the acquirer-side supplier-relationship security standard. Manufacturers subject to CRA flow their supplier-side obligations down through ISO/IEC 27036 contract clauses to their own suppliers; acquirers buying CRA-scoped products read CRA conformity as one input into the ISO/IEC 27036 assurance posture per supplier.

ISO/IEC 27036 vs SOC 2 CC9.2 (Vendor and Business Partner Risk)

SOC 2 Common Criteria CC9.2 covers the entity-side management of vendor and business partner risk. ISO/IEC 27036 reads beneath CC9.2 as the operating standard the vendor risk programme runs against. SOC 2 auditors increasingly read the supplier inventory, the assessment cadence, the incident-notification handling, and the termination evidence; ISO/IEC 27036 supplies the shape of the artefact pack CC9.2 reads against.

ISO/IEC 27036 vs HIPAA Business Associate Agreements

HIPAA Security Rule and Privacy Rule require Business Associate Agreements (BAAs) between covered entities and their business associates handling protected health information. ISO/IEC 27036 reads as the operating standard the BAA contract clauses, the assessment cadence, the incident-notification handling, and the termination discipline read against. Covered entities operating against HIPAA use ISO/IEC 27036 as the structural reference and the BAA template as the legal artefact.

ISO/IEC 27036 vs CSA STAR and ISO/IEC 27017 (cloud)

Part 4 of ISO/IEC 27036 covers cloud service consumption specifically. CSA STAR is the cloud-provider assurance regime. ISO/IEC 27017 is the cloud-specific control extension to ISO/IEC 27002. Cloud-heavy supplier programmes read all three together: 27036-4 supplies the supplier-relationship discipline for cloud, STAR supplies the published provider assurance the acquirer reads, and 27017 supplies the cloud-control specifics that fill in the Annex A 5.23 (information security for use of cloud services) evidence.

Where ISO/IEC 27036 sits next to other framework pages

ISO/IEC 27036 is the supplier-relationship operating standard; the adjacent framework pages cover the regimes the supplier programme reads alongside. The pages below are the ones supplier-security programmes most often read together.

  • The ISO/IEC 27001 framework page covers the certifiable ISMS standard. Annex A 5.19 to 5.23 are the supplier-relationship controls; ISO/IEC 27036 is the deeper implementation companion that explains how to operate those controls.
  • The NIST SP 800-161 framework page covers the federal C-SCRM strategy and the SR control family in NIST SP 800-53 Rev. 5. Programmes operating against both regimes use 800-161r1 as the strategy spine and ISO/IEC 27036 as the supplier-relationship companion.
  • The DORA framework page covers the EU Digital Operational Resilience Act for financial entities. Article 28 imposes detailed third-party ICT risk obligations that read against the same supplier inventory, contract pack, and operating cadence ISO/IEC 27036 expects.
  • The NIS2 framework page covers the EU directive on cybersecurity for essential and important entities. Article 21(2)(d) requires supply chain security management that ISO/IEC 27036 supplies the operating standard for.
  • The EU Cyber Resilience Act framework page covers the product-side supply-chain obligations for products with digital elements placed on the EU market. ISO/IEC 27036 is the acquirer-side supplier-relationship discipline manufacturers flow CRA obligations down through.
  • The CSA STAR framework page covers the cloud-provider assurance regime. Part 4 of ISO/IEC 27036 is the cloud-service relationship discipline; STAR Registry entries are one input the acquirer reads against the supplier assurance posture per cloud provider.
  • The ISO/IEC 27017 framework page covers the cloud-security control extension to ISO/IEC 27002. Cloud-heavy supplier programmes read 27036-4, STAR, and 27017 together to cover the cloud-relationship, provider-assurance, and cloud-control evidence layers.
  • The SOC 2 framework page covers the AICPA Trust Services Criteria. CC9.2 (vendor and business partner risk) reads against the same supplier inventory, assessment cadence, and termination evidence ISO/IEC 27036 expects.
  • The HIPAA framework page covers the US healthcare regime. Business Associate Agreements are the legal artefact; ISO/IEC 27036 reads beneath as the operating standard for the BAA programme.
  • The ISO/IEC 27031 framework page covers ICT readiness for business continuity (IRBC). The supplier-side BCDR clause in ISO/IEC 27036-2 reads against ISO/IEC 27031 as the standards-side ICT continuity reference so the acquirer-side recovery posture does not assume supplier-side readiness without evidence.

Where SecPortal fits in an ISO/IEC 27036 programme

SecPortal is the operating layer for the supplier-relationship lifecycle, not a replacement for the standard itself, not a contract lifecycle management platform, and not a vendor risk rating service. The platform handles the workstreams that produce the ISO/IEC 27036 Part 2 evidence (engagement structure for the per-cycle supplier work, finding intake from supplier-side advisories and acquirer-side technical assessments, severity scoring under CVSS 3.1, retest evidence paired to the original finding, exception register with named owner and expiry, document management for the contract pack and the assurance evidence, the activity log auditors and regulators read against). The same workspace that hosts the supplier engagement record hosts the scan-side evidence the technical assessment depends on, so the line from clause to evidence stays traceable.

  • Engagement management dedicated to the supplier-relationship operating cycle, with per-quarter cycles per high-risk supplier and event-driven cycles for incident notification, vulnerability notification, sub-processor change, and renewal preparation, so the ISO/IEC 27036 cadence reads as scheduled work rather than reactive triage
  • Findings management with CVSS 3.1 scoring, CWE tags, and structured fields so the supplier-channel vulnerabilities raised through supplier notifications, technical assessments, and pentests feed the same record the direct-channel vulnerabilities use, and the Part 3 vulnerability-handling expectation is evidenced without bifurcating the vulnerability programme
  • Bulk finding import that converts supplier-side assurance artefacts (ISO/IEC 27001 audit findings, SOC 2 exceptions, STAR Continuous per-cycle evidence, third-party pentest reports, security questionnaire residuals) into structured findings on the workspace, so the supplier-relationship record reads alongside the direct-channel scan and pentest record
  • Document management for the supplier inventory snapshot exports, the per-supplier contract pack, the assurance evidence files (ISO/IEC 27001 certificate, SOC 2 Type II report, STAR Registry entry, FedRAMP authorisation, sector certification, completed questionnaire), the data processing addenda, the standard contractual clauses pack, the transfer impact assessments, and the termination evidence, with version history per artefact and named custodian per file
  • Activity log with CSV export that captures every state change to a supplier record, an assessment, a contract amendment, an incident notification, a vulnerability notification, a sub-processor change, a residual-risk acceptance, or a termination event, so an internal auditor, an external auditor, a regulator, or an audit committee can reconstruct the supplier-relationship lifecycle without a multi-team excavation
  • Compliance tracking that reads the same supplier-programme evidence pack across ISO/IEC 27001 Annex A 5.19 to 5.23, NIST SP 800-161r1 SR control family, SOC 2 CC9.2 (vendor and business partner risk), HIPAA BAA expectations, DORA Article 28 (third-party ICT risk), NIS2 Article 21(2)(d) (supply chain security), the EU Cyber Resilience Act supplier-side flow-down, and the sector regulator reads (FFIEC, EBA, MAS TRM, APRA CPS 234, RBI, HKMA)
  • Continuous monitoring schedules (daily, weekly, biweekly, monthly) that establish the per-cycle external-scan baseline against supplier-managed assets in scope of the relationship, so the supplier-side exposure surface reads alongside the supplier-side assurance evidence rather than as separate tracks
  • External scanning and authenticated DAST that produce the technical-assessment side of the high-risk supplier review, so the per-cycle ISO/IEC 27036-2 assessment includes the technical baseline rather than relying on the supplier-side attestation alone, and the residual gap surfaces back into findings management with a path to remediation
  • Code scanning (Semgrep-based SAST and dependency analysis) with GitHub, GitLab, and Bitbucket OAuth that produces the first-party software side of the supplier-relationship record where the supplier consumes the acquirer software supply (rare but real for partnership and platform relationships) and the dependency analysis surfaces the supplier components feeding the acquirer build
  • Team management with role-based access (owner, admin, member, viewer, billing) that keeps procurement, legal, vendor risk, security, finance, and the business owner on the same workspace with appropriate scoping per supplier category and per business line
  • Multi-factor authentication enforcement at workspace level for the supplier-relationship records, so the same identity assurance the standard expects for the operating record applies at access time as well as evidence time
  • AI report generation that turns the operating supplier-relationship record into an audit-committee narrative, a regulator pack (DORA Register of Information, NIS2 supply chain disclosure, HIPAA BAA programme summary), and an executive sponsor briefing without rewriting the underlying record

What SecPortal does not do

ISO/IEC 27036 is a lifecycle standard that depends on the acquirer operating procurement, legal, vendor risk, and security as a coordinated function. SecPortal is the operating record, not the contract lifecycle management platform, not the vendor risk rating service, and not the third-party audit firm. The honest scope below reads against the ISO/IEC 27036 boundary so the platform commitment is unambiguous.

  • SecPortal is not a contract lifecycle management (CLM) platform. The platform does not negotiate, redline, sign, or store the legal contract itself as a CLM record; the legal contract record lives in the CLM, the procurement system, or the document repository the legal and procurement functions already use. SecPortal carries the operating record the contract clauses read against and the supplier-relationship operating loop the contract obligations are exercised through.
  • SecPortal does not connect to ServiceNow vendor risk, OneTrust, ProcessUnity, Aravo, BitSight, SecurityScorecard, RiskRecon, UpGuard, Prevalent, CyberGRX, or Whistic. The vendor risk platforms own the questionnaire orchestration and the rating ingestion; SecPortal carries the per-supplier evidence pack alongside the residual-risk acceptance record and the operating cadence.
  • SecPortal does not run the regulator notification on the acquirer behalf. GDPR Article 33 supervisory authority notification, NIS2 Article 23 CSIRT notification, DORA Article 19 ICT-related incident reporting, SEC Item 1.05 material event filing, sector-specific clocks: the acquirer notifies, and SecPortal carries the evidence record the notification reads against and the contract clause the supplier obligation reads against.
  • SecPortal does not auto-complete the supplier security questionnaire. The questionnaire response is the supplier-side artefact the acquirer reads; the workspace carries the received response with version control and the evidence references the questions ask for. The acquirer reviewer reads the response against the contract baseline.
  • SecPortal does not perform the third-party audit. ISO/IEC 27001 certification is performed by an accredited certification body. SOC 2 examinations are performed by an accredited CPA firm. CSA STAR Level 2 audits are performed by certification bodies and CPA firms. SecPortal carries the published assurance evidence with the validity tracking; the audit firm performs the audit.
  • SecPortal does not replace the human supplier relationship owner, the accountable procurement lead, or the legal counsel that owns the contract clauses. The platform carries the operating record so the relationship work is durable rather than tribal; the named relationship owner runs the relationship, the procurement lead negotiates the renewal, and the legal counsel reads the clauses.
  • SecPortal does not issue or verify trusted-supplier seals. The supplier-relationship security posture is the per-acquirer reading against the per-supplier evidence; there is no industry-issued trusted-supplier seal SecPortal can stand for or against.

The supplier-side workstreams the lifecycle reads against already exist as named use cases on SecPortal. The vendor security questionnaire response workflow covers the supplier-side questionnaire turnaround the acquirer-side review reads against. The third-party penetration test report intake workflow covers the acquirer-side ingestion of supplier-side pentest reports into the same findings record the direct-channel testing produces. The SBOM management and VEX publishing workflow covers the software-supplier transparency obligations the ICT supply chain part of the standard reads against. The cross-framework control mapping workflow reads the same supplier evidence pack across ISO/IEC 27036, NIST SP 800-161r1, DORA Article 28, NIS2 Article 21(2)(d), SOC 2 CC9.2, HIPAA BAA expectations, and the EU Cyber Resilience Act so the cross-regime read is reconcilable rather than reconciled per audit. The audit evidence retention and disposal workflow carries the retention and disposal discipline the contract data-return and data-destruction clauses read against.

For GRC and compliance teams running the cross-regime supplier programme, the GRC and compliance teams workspace bundles the platform with the engagement structure the supplier audit cadence reads against. For internal security teams running the technical-assessment side of the supplier programme, the internal security teams workspace covers the per-cycle technical assessment, the incident-notification handling, and the vulnerability-notification handling the operating loop runs through. For CISOs and security leaders carrying the audit-committee read against the third-party risk posture, the CISOs and security leaders workspace covers the board-side reporting model that sits on top of the supplier-relationship operating record.

For deeper reading on the disciplines this standard reads against, the third-party vendor risk assessment guide covers the buyer-side third-party risk discipline ISO/IEC 27036 reads alongside. The software supply chain security guide covers the software-side supply-chain regime Part 3 reads against, with SBOM, VEX, SLSA, SSDF, and CRA tied together. The DORA ICT third-party risk management implementation guide covers the financial-services-specific operating shape of the supplier-relationship discipline DORA Article 28 reads against. The non-human identity security guide covers the supplier-side machine-identity discipline that often lives outside the headline supplier inventory and surfaces during incident handling. The security control drift research covers the patterns that erode supplier-relationship evidence between annual reviews when the assurance is refreshed only at audit time.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Part 1: Overview and concepts

The orientation part. Defines the supplier-relationship vocabulary the rest of the standard reads against (acquirer, supplier, supplier relationship lifecycle, supplier categorisation, information security risks in supplier relationships) and names how 27036 sits alongside ISO/IEC 27001 Annex A 5.19 to 5.23 and the wider ISO 27000 family.

Part 2: Requirements (the only normative part)

Lists the requirements an acquirer and a supplier each carry across the supplier-relationship lifecycle (planning, supplier selection, agreement establishment, agreement management, agreement termination, post-agreement disposal). Conformity to ISO/IEC 27036 is conformity to Part 2. The other parts are guidance that explains how to operate Part 2 in context.

Part 3: Guidelines for ICT supply chain security

Adds the supply-chain context to the supplier-relationship requirements: hardware, software, and service supply chains, the tiered supplier model (Tier 1, Tier 2, Tier 3 and beyond), supply chain traceability, integrity of components in transit and at handoff, and the inheritance of obligations down the supplier chain. Reads alongside NIST SP 800-161 and the EU Cyber Resilience Act.

Part 4: Guidelines for security of cloud services

Tailors the supplier-relationship requirements to cloud service consumption: cloud customer and cloud service provider as the acquirer and supplier in cloud terms, the shared responsibility model, the cloud-specific information security risks, the cloud-specific contract clauses (location of processing, sub-processor management, exit and portability, incident notification), and the cloud-specific monitoring and assurance reads.

The six lifecycle phases

ISO/IEC 27036 is a lifecycle standard. The six phases are planning (define requirement, risks, categorisation), supplier selection (due diligence proportionate to category), agreement establishment (security clauses become binding), agreement management (operate the relationship, longest phase), agreement termination (wind down per contract terms), and post-agreement disposal (confirm disposal, archive evidence). Each phase has named requirements in Part 2.

Supplier categorisation patterns

ISO/IEC 27036 expects the supplier set to be categorised so the assessment cadence and contract templates match the risk per relationship. Dimensions include commodity vs strategic, single-source vs multi-source, direct vs sub-supplier (Tier 1/2/3), low-risk vs high-risk by data class, onshore vs offshore vs cross-border, and new vs incumbent. Single-dimension categorisation under-weights relationships that look low risk on one axis and high risk on another.

The minimum agreement clause set

Part 2 expects security expectations to land in the contract. The minimum clause set covers information security controls, data handling and classification, sub-processor management, security incident notification (24 to 72 hours typically), vulnerability notification, audit and assurance rights, business continuity and disaster recovery, data return and destruction at termination, termination assistance, and personnel security. The clause set ties to GDPR Article 33, NIS2 Article 23, and DORA Article 19 downstream notification clocks.

The acquirer-side evidence pack

The auditor, the regulator, and the audit committee each read a defined evidence pack against the supplier programme: the supplier inventory, the supplier risk assessment record, the supplier assessment evidence (questionnaire response, published assurance, technical assessment), the contract pack with amendments and DPAs, the incident notification log, the vulnerability notification log, the audit log, the BCDR evidence, the termination record, and the supplier KPI record per relationship.

Cross-walk to NIST SP 800-161r1 and DORA Article 28

ISO/IEC 27036 reads alongside NIST SP 800-161r1 as the international supplier-relationship vocabulary that complements the federal-grade C-SCRM strategy. Financial entities subject to DORA Article 28 (third-party ICT risk) operate ISO/IEC 27036 as the operating standard the contract clauses, the Register of Information, and the exit strategies read against. The two regimes share artefacts; the cross-walk avoids parallel evidence packs.

Cross-walk to NIS2 Article 21(2)(d) and the EU Cyber Resilience Act

NIS2 Article 21(2)(d) requires essential and important entities to manage supply chain security. The EU Cyber Resilience Act obliges manufacturers to maintain SBOM, vulnerability handling, and lifecycle security obligations. ISO/IEC 27036 reads beneath both regimes: NIS2 as the operating standard for supply chain security management, CRA as the acquirer-side supplier-relationship discipline through which manufacturers flow CRA obligations down to their own suppliers.

Cross-walk to SOC 2 CC9.2, HIPAA BAA, and ISO 27001 Annex A 5.19 to 5.23

SOC 2 Common Criteria CC9.2 (vendor and business partner risk) reads against the same supplier inventory, assessment cadence, and termination evidence ISO/IEC 27036 expects. HIPAA Business Associate Agreements are the legal artefact; ISO/IEC 27036 reads beneath as the operating standard for the BAA programme. ISO/IEC 27001 Annex A 5.19 to 5.23 are the supplier-relationship controls in the certifiable ISMS standard; ISO/IEC 27036 is the deeper implementation companion.

Cross-walk to CSA STAR, ISO/IEC 27017, and the cloud-services regime

Part 4 of ISO/IEC 27036 covers cloud service consumption specifically. CSA STAR is the cloud-provider assurance regime the acquirer reads as one input into the supplier assurance posture. ISO/IEC 27017 is the cloud-security control extension to ISO/IEC 27002 that fills in the Annex A 5.23 (information security for use of cloud services) evidence. Cloud-heavy supplier programmes read 27036-4, STAR, and 27017 together.

Related features

Compliance tracking without a full GRC platform

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Monitor continuously catch regressions early

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

Multi-factor authentication on every workspace

Bulk finding import bring your scanner data with you

AI-powered reports in seconds, not days

Verify fixes and track reopens on the same finding record

Finding overrides that survive every scan cycle

Run the ISO/IEC 27036 supplier programme on one workspace

Hold the supplier inventory, the contract pack, the assurance evidence, the incident and vulnerability notification log, the assessment cadence, the BCDR evidence, and the termination record on one operating workspace. Carry the same record into NIST SP 800-161, DORA Article 28, NIS2 Article 21(2)(d), SOC 2 CC9.2, HIPAA BAA, the EU Cyber Resilience Act, and CSA STAR without rebuilding the evidence pack. Start free.

Get Started Free

No credit card required. Free plan available forever.