Cyber supply-chain risk management policy

Cyber supply-chain risk management policy

SC-01 — Supply-chain policy and scope

[Organisation] manages cybersecurity supply-chain risk for the products and services on which its systems depend. The programme covers acquisition, integration, operation, maintenance and disposal. It includes commercial suppliers, service providers, open-source components, development tools, hosting, managed services, data sources and AI models or services where they contribute to the system or its delivery environment.

The programme owner establishes the organisational approach and resources. System owners identify how supply-chain dependencies affect their systems. Supplier owners maintain the relationship, assessment and monitoring records. The approach connects organisational priorities, system risk and individual acquisition decisions, using the multi-level perspective of NIST SP 800-161 Rev. 1 as a reference.

SC-02 — Inventory and criticality

The supplier owner maintains an inventory of relevant providers, products, services and dependencies, including the system functions they support. Entries identify the legal or project identity, product or service, version where applicable, source, responsible organisational owner and support arrangements. The inventory distinguishes a supplier relationship from a software component; one supplier may provide several dependencies and one component may have several distribution sources.

The owner evaluates criticality by considering the consequence of loss, compromise, incorrect output, unsupported status or inability to replace the dependency. The evaluation includes access to sensitive information, privileged system access, update authority, concentration of reliance and substitutability. Criticality determines the assessment and monitoring effort through a recorded decision; the policy does not assume that all dependencies can receive the same depth of review.

SC-03 — Assessment and selection

Before committing to a material dependency, the owner identifies applicable security, privacy, resilience and evidence requirements. The assessment examines the provider’s ability to meet them and records the scope and currency of evidence. Claims, contractual commitments and independently assessed facts remain distinguishable. Unanswered questions are recorded as unknowns, with their effect on the decision.

Assessment includes product provenance, secure development practices, vulnerability handling, update mechanisms, access and data processing, operational support, incident notification and exit capability as relevant. The owner identifies downstream dependencies that materially affect the service. Where visibility is limited, the risk record states the limitation and the reliance being accepted. Lack of complete upstream visibility is handled as a decision context, not concealed by an empty questionnaire field.

SC-04 — Agreements and responsibilities

The agreement identifies the requirements the provider accepts, the evidence to be supplied, the responsibilities retained by [Organisation], and the process for changing the arrangement. Relevant conditions include access, data use, locations, subcontractors, support, incident communication, vulnerability response, update integrity, continuity and termination. The supplier owner confirms that internal expectations match the executed agreement.

For community-maintained software or other dependencies without a negotiable agreement, the owner records the available maintenance and disclosure arrangements, internal responsibilities and risk decision. A community project is not represented as having accepted a contractual promise it never made. Internal controls and replacement options are considered where external commitments are unavailable.

SC-05 — Provenance and integrity

The engineering owner records the origin and version of incorporated software, data, models and other relevant components. The record identifies acquisition source, integrity information available, modifications and the release in which the component is used. Verification checks the received artefact against the expected source and integrity mechanism where one exists. The absence or limitation of provenance is recorded explicitly.

Build and release records connect component versions to delivered artefacts. The owner maintains dependency information sufficiently to identify affected systems when a supplier or component issue is reported. A software bill of materials supports that identification but is not treated as a complete supplier assessment or proof that the listed components are free of vulnerabilities.

SC-06 — Monitoring and response

The supplier owner monitors the events and review dates recorded for the dependency. Relevant events include vulnerabilities, compromise, ownership or subcontractor changes, altered data practices, service degradation, support withdrawal, changed update behaviour and loss of required assurance evidence. The owner evaluates the effect on system requirements and risk decisions and coordinates action with engineering, privacy and operations.

Supplier incidents and product integrity concerns enter the incident or vulnerability process as appropriate. The record identifies affected versions and systems, interim measures, communication and the decision on continued use. Changes to a critical dependency can trigger requirements, architecture, threat or release reassessment. A renewed commercial subscription does not by itself renew a security assessment.

SC-07 — Exit and assurance

The owner records how the organisation can continue essential work, recover its information and remove supplier access when the relationship ends. The plan includes data export, deletion or return evidence, transition assistance, retained records and dependencies that may prevent replacement. Exit assumptions are reviewed before they become urgent operational decisions.

At [schedule], assurance checks selected dependencies from acquisition decision through current use. The review verifies that the assessment covers the actual service and version, agreed responsibilities are performed, monitoring events are acted upon and exit arrangements remain feasible. Findings identify unowned dependencies, unsupported assurances and differences between the agreement and operational practice.

Supply-chain record: [SC ID; supplier/product/service; source]
System and function supported: [System IDs; dependency; criticality]
Owner and contact: [Internal owner; external support/security contact]
Assessment and agreement: [Evidence; date; requirements; accepted gaps]
Provenance and versions: [Component records; integrity; modifications]
Monitoring: [Schedule; events; source; responsible person]
Exit and continuity: [Replacement; export; access removal; evidence]
Current decision: [Authority; conditions; review date; risk IDs]