ISO/IEC 27036 ICT Supply Chain Lifecycle

Define the system or service, intended use, critical functions and elements, information flows, direct suppliers, known upstream dependencies, delivery paths, development and support locations, update mechanisms, and end-of-support assumptions. The boundary should cover components and services whose compromise, failure, substitution, or loss of support could change the risk.

Set the needed level of visibility and traceability from risk. Part 3 does not require complete knowledge of every upstream entity for every acquisition; it recommends selecting relevant activities according to the risk presented by the supplier, acquirer, and relationship.

Example: for a network appliance, the boundary can include the hardware manufacturer, critical firmware components, approved distributor, signing and update service, remote-maintenance path, and end-of-support date. For software as a service, it can include the application supplier, material cloud infrastructure and identity dependencies, deployment pipeline, privileged support, data locations, and export or deletion path.

During design and implementation, control access to development and production environments, protect design and build information, assess component and service choices, test security properties, and record approved configurations. During delivery and transition, use authorized sources and agreed methods to verify identity, integrity, version, configuration, custody, and acceptance where the risk requires them.

During operation and maintenance, monitor supplier performance, vulnerabilities, incidents, anomalous behavior, update integrity, configuration change, component authenticity, support status, and supplier business health as applicable. Reassess risk when findings or changes affect a critical element or an accepted assumption.

At replacement or disposal, protect information, remove access and secrets, preserve required records, sanitize or destroy media and components as appropriate, prevent disposed or counterfeit items from re-entering trusted supply, and verify completion.

Planning evidence includes the system boundary, critical-element analysis, risk assessment, supply-chain map with stated visibility limits, security requirements, sourcing decision, selected suppliers, and agreements. Engineering evidence includes architecture and design decisions, provenance information, bills or inventories of components where used, build and release records, test results, and accepted configurations.

Delivery and operating evidence includes authorized-source records, integrity or authenticity checks, acceptance results, configuration history, vulnerability and update decisions, incident records, supplier reviews, continuity tests, corrective actions, and end-of-support plans.

Traceability does not mean collecting documents without a decision. Each record should identify the item or service, version, supplier, lifecycle stage, covered period, reviewer, result, limitations, and follow-up.

Reopen the assessment when a critical component, supplier, manufacturing or hosting location, build or update path, privileged maintainer, architecture, ownership, support status, threat, vulnerability, or legal or contractual requirement changes. A proposed substitution should be assessed before acceptance when the original item or source formed part of the risk decision.

Treat end of support, supplier failure, merger or acquisition, loss of an authorized source, and inability to obtain security updates as lifecycle events. Decide whether to replace, isolate, add controls, reduce use, or accept the time-limited risk.

At termination or disposal, coordinate continuity and transition, remove access, credentials, and signing or support trust, return assets, return or dispose of information, preserve required evidence, and record dependencies that remain.