Part of Objective A - Managing risk
Principle: A4 Supply chain
A4.a Supply chain
"You understand and effectively manage the security and information governance risks associated with suppliers supporting the operation of your essential function(s)."
Overview
This contributing outcome is about ensuring your organisation has factored cyber security and information governance (IG) considerations into your approach to working with suppliers.
Supply chain risk
It is your responsibility to understand the risks posed to the operation of your essential function by your supply chain, and to put appropriate controls in place to mitigate those risks.
As part of your scoping exercise, you should have identified the information, systems and networks supporting your essential functions which are administered by, require the involvement of, or may be affected by suppliers. From here, you can work to understand what controls you need in place to ensure the governance and security of those supplier systems.
Appropriate and proportionate levels of cyber security
Your suppliers should be able to demonstrate appropriate and proportionate levels of cyber security within the context of common threats.
They can evidence this through their completion of a recognised assurance framework designed to defend corporate networks and products against such threats, including:
Data Security and Protection Toolkit (DSPT)
Contracts
You should conduct a review and ensure that appropriate cyber security and data protection obligations are included in relevant contracts. As part of your review, you should consider all suppliers providing services or systems involved in the operation of your essential functions and all suppliers with access to personal data and confidential patient information.
Cyber security obligations
You should determine which cyber security obligations you include in supplier contracts based on the service being provided, and the risk to your essential functions if the supplier were to become compromised by an incident.
Examples of cyber security obligations to consider are:
- right to audit – the right to conduct audits of the supplier’s infrastructure, systems, services and premises with appropriate notification, or in case of an incident
- incident management – the requirement for suppliers to inform your organisation of ongoing incidents and any impacts to your organisation
- assurance – the requirement for the supplier to provide appropriate assurance evidence at the commencement of the contract and regularly throughout the lifetime of the contract (the specific requirements around this will vary depending upon system and data sensitivity)
- service level agreements (SLAs) – these should also include security service levels covering out of hours support and reporting, handling and remediation of incidents
- vulnerability management – the requirement for the supplier to keep the system, service or software patched and on up-to-date operating systems
- security governance – the expectations of the organisation around security governance within the supplier, including security risk management and signing off residual risks
Organisations are responsible for seeking their own legal advice and ensuring any contracts they sign are fit for purpose.
Data protection obligations
Any contracts or agreements with suppliers must have the appropriate clauses in place to cover the requirements of data protection legislation. If you are asking a supplier to process on your behalf, you must have a legally binding document to cover your processing instructions to the supplier. See the ICO’s guidance on Contracts for more information on data protection requirements.
NHS England has produced a universal data sharing and processing agreement (DSPA) template containing all of the necessary clauses needed to comply with UK GDPR and the common law duty of confidentiality. The NHS terms and conditions for the procurement of goods and non-clinical services also covers relevant UK GDPR requirements.
Organisations are responsible for seeking their own legal advice and ensuring any contracts they sign are fit for purpose.
Third party connections
Third-party connections are connections from outside organisations or people to your systems or network. For example, this could include a supplier using their own system to manage or support a service in your organisation’s IT environment. You should obtain assurance that all third party connections to your network meet your security and IG requirements.
You should have a standard process for allowing third party connections to systems on your network. As part of the approval process, third parties’ connections should be documented with appropriate justifications for why they are needed.
Not every third party connection requires the same depth of assurance. For example, members of the public accessing your organisation’s website are third party connections to your organisation’s systems, but cannot be individually assured. Alternative controls should be used to mitigate security risks arising from third party connections of this nature instead.
Incidents arising in your supply chain
You should consider data security and protection incidents that might arise in your supply chain. This consideration of supply chain incidents may be reflected in a number of documents, including your due diligence processes, your incident response plans, and the contracts and agreements you have in place with suppliers.
Any supplier incidents or near misses that have a data security or data protection implication should be recorded.
"Achieved" level 7
Deep supply chain understanding
You need to have a deep understanding of your supply chain and the wider risks it faces.
A proportionate approach would be to do in-depth analysis of risks relating to suppliers who are critical to your essential functions. You can devise your own way of categorising “critical”, which is likely to consider whether a supplier’s systems would have a particularly high impact across your essential functions if compromised.
Your in depth analysis for critical suppliers could include:
- identifying and documenting subcontractors that are material to the service which the supplier provides to you
- considering how disruption, compromise or poor performance at subcontractor level could affect your organisation, even where you do not contract with that subcontractor directly
- assessing risks, such as concentration risk and over-reliance on a single provider
- recording any gaps in visibility or assurance and assessing the associated risk
Procurement lifecycle processes and purchasing decisions
Your organisation should have a structured supplier risk assessment and due diligence process.
As part of this process, you should gather information about:
- the supplier’s approach to IG and cyber security
- the supplier’s ownership, corporate structure, parent company, country of operation, hosting locations and support locations
- whether the supplier uses subcontractors or other third parties to deliver the service, and who these are
- the supplier’s wider commercial relationships and partnerships
You should record the outcome of this assessment and use it to inform procurement decisions, contract clauses, approval of supplier access to information and contingency planning.
Where information is incomplete or assurance is limited, you should record the gap, assess the risk, and where possible put mitigating controls in place.
Subversion by capable and well resourced threat actors
You should consider the risks to your essential functions arising from supply chain subversion by capable and well-resourced threat actors.
You can do this by factoring supply chain subversion into your activities described in Threat modelling guidance A2b Understanding threat.
Assurance against capable and well-resourced threat actors
Your critical suppliers must demonstrate appropriate and proportionate levels of cyber security, and you must have confidence in the information they hold, within the context of capable and well resourced threat actors.
To achieve this, after factoring supply chain subversion into your activities described in Threat modelling guidance in A2.b Understanding threat, you should be able to judge that the security controls your suppliers have in place are sufficient to mitigate against the scenarios you have worked through.
Proactive approach to contract management
You should have a proactive approach to contract management.
This means that factors that you consider in your procurement decisions to choose suppliers are revisited for those same suppliers on a scheduled basis rather than being a one off procurement exercise.
These factors may reflect those described in Procurement lifecycle processes and purchasing decisions
Network connections and data sharing with third parties
You should manage all third party network connections and data sharing with third parties effectively and proportionately.
You should document third party network connections, including why they are needed, what systems or data they involve, and who is responsible for approving and reviewing them. You should re-evaluate whether connections should continue to be authorised where significant events occur such as:
- a change to the system being connected to
- a security incident, near miss, or audit finding affecting the supplier
- a change to the service or business need
- a change to your own organisation’s security or IG requirements
- the supplier no longer meeting your organisation’s assurance requirements
Your data sharing activities should be captured in your ROPA. You can use this to govern what data is being shared with third parties and ensure it is proportionate.
Supporting evidence
To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:
- documentation showing supplier risks to essential functions
- lists of suppliers and sub-contractors
- supplier contracts
- documentation showing third party connections
- evidence of supply chain incidents being considered as part of supplier assurance and incident management
- evidence of international data transfers being considered as part of supplier management processes
- documentation showing in-depth analysis of risks relating to suppliers who are critical to essential functions
- procedures for supplier risk management
- evidence of threat modelling activities and consideration of supply chain subversion
- evidence of due diligence being refreshed on a scheduled basis
- evidence of authorisations for third party connections being re-evaluated based on significant events
- evidence of data sharing activities being appropriately managed
- supplier assurances of incident support
This is not an exhaustive list. You can provide other types of evidence if you feel they are relevant to the contributing outcome.
Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate.
Interpreting indicators of good practice
| Indicator(s) of good practice | Term | Interpretation |
|---|---|---|
|
PA#1 You understand the general risks suppliers may pose to your essential function(s). |
'essential function(s)' |
Your essential functions should be identified in a scoping exercise which you carry out before beginning your DSPT submission. The same exercise should identify all the information, systems and networks which support your essential functions. For more information, see guidance on scoping essential functions. |
|
PA#2 You know the extent of your supply chain that supports your essential function(s), including sub-contractors. |
'including sub-contractors' |
You are not expected to identify every individual subcontractor of all your suppliers for achievement of this outcome. You should determine a list of “critical suppliers” based on them supporting your information or technology assets, which would have the biggest impact on your essential functions if compromised. Determining “critical suppliers” is a case of local judgment. For those critical suppliers, proportionate efforts should be made to identify sub-contractors which, if compromised, could have a big impact on your delivery of essential services. You are only expected to do what is practicable in identifying sub-contractors with a substantial role in supporting your key information or technology assets. |
|
PA#4 You understand which contracts are relevant and you include appropriate security and data protection obligations in relevant contracts |
'relevant contracts' |
This applies to all contracts you have that may have a cyber security or data protection impact. This will include, for example, catering services if they handle personal data that includes patient names and dietary requirements, and any supplier whose service includes an IT component. |
|
PA#7 You have confidence that information shared with suppliers that is necessary for the operation of your essential function(s) is appropriately protected from well-known attacks and known vulnerabilities. |
'information shared with suppliers' | Provided you have considered guidance above relating to Appropriate and proportionate levels of cyber security, Contracts and Incidents arising in your supply chain, there is no additional assurance required by the DSPT for having confidence that information shared with suppliers is appropriately protected as described in PA#7.
|
|
PA#8 All international data transfers to suppliers are covered by a legal protection. |
'legal protection' |
You must be aware of all countries where data is being processed as part of any supplier-offered service. This should be documented in your information assets and flows register (see A3.a Asset management and B3.a Understanding data Where data is being processed by suppliers located in countries with no adequacy regulations, you must have an International Data Transfer Agreement (IDTA) in place. You can reference the IDTA documents within other agreements (such as NHS England’s template data sharing and processing agreement (DSPA) or NHS standard terms and conditions for the procurement of non-clinical goods and services if needed. |
National services
The following national services may help you meet the requirements of A3.a Asset management:
- Training services | Board training
- Training services | Cyber Incident Response Exercise (CIRE)
- Security services | Cyber Assurance Service (CAS)
- NCSC services | Exercise in a box
Additional guidance
For additional guidance, see:
National Cyber Security Centre CAF guidance | A4 Supply chain
National Cyber Security Centre | Supply chain
Information Commissioner’s Office | Contracts and data sharing
A4.b Secure software development and support
“You actively maximise the use of secure and supported software, whether developed internally or sourced externally, within network and information systems supporting the operation of your essential function(s).”
Software developed in-house
Where your organisation develops software in-house, your internal software development team effectively becomes the “software supplier” referred to in the indicators of good practice for this outcome.
You should have procedures covering the development, testing, approval, deployment and support of software your internal software development team produces.
Assurance approach for software suppliers
The indicators of good practice for the “Partially Achieved” category of this outcome align with the principles set out in the software security code of practice created by the Department for Science, Innovation and Technology (DSIT) and the National Cyber Security Centre (NCSC).
To meet the “Partially Achieved” level, organisations can therefore use assurance mechanisms connected to the software security code of practice to obtain assurance from suppliers that the requirements of this outcome are being met.
All of the following assurance mechanisms require suppliers to follow the software security code of practice:
- signing up to the cyber security charter for suppliers to the NHS
- being categorised into the “large IT supplier ” DSPT category and having a valid DSPT return at Standards Met
- completing a Digital Technology Assessment Criteria (DTAC) assessment for the digital health technology product being sold into your health or care organisation
If a supplier has undertaken one or a number of these actions, they have formally declared that they are following the principles of the software security code of practice for the product they are providing to the health and care sector. This should not deter you from seeking specific assurance from the supplier regarding their software where this would help confirm compliance and avoid ambiguity.
For higher-risk suppliers or systems, you may decide that further assurance is needed, such as using the NCSC’s assurance principles and claims assessment.
Software security code of practice principles
Below is a table illustrating how the indicators of good practice for this outcome align to principles in the software security code of practice.
| Areas covered by indicators of good practice | Software security code of practice principles |
|---|---|
| Secure development principles and practices (PA#1) |
1.1 Follow an established secure development framework. 1.4 Follow secure by design and secure by default principles throughout the development lifecycle of the software |
| Composition and provenance of software (PA#2) |
1.2 Understand the composition of the software and assess risks linked to the ingestion and maintenance of third party components throughout the development lifecycle |
| Security of environments (PA#3) |
2.1 Protect the build environment again unauthorised access 2.2 Control and log changes to the build environment |
| Functional and non-functional testing (PA#4)
|
1.3 Have a clear process for testing software and software updates before distribution |
| Updates, patches and notifications (PA#5) | 3.5 Provide timely security updates, patches and notifications to customers. |
| Secure transmission channels (PA#6) | 3.1 Distribute software securely to customers. |
| Identifying, reporting and mitigating security vulnerabilities (PA#7) |
3.3 Have processes and documentation in place for proactively detecting, prioritising and managing vulnerabilities in software components 3.4 Report vulnerabilities to relevant parties where appropriate |
| Notification of significant events (PA#8) | 3.5 Provide timely security updates, patches and notifications to customers. |
| Security of open-source software (PA#9) |
1.2 Understand the composition of the software and assess risks linked to the ingestion and maintenance of third party components throughout the development lifecycle |
| Appropriate support and maintenance arrangements (PA#10) |
4.1 Provide information to the customer specifying the level of support and maintenance provided for the software being sold 4.2 Provide at least 1 year’s notice to customers of when the software will no longer be supported or maintained by the vendor 4.3 Make information available to customers about notable incidents that may cause significant impact to customer organisations |
“Achieved” level
Assurance approach for software suppliers
Your assurance approach should involve obtaining more specific assurances from suppliers.
For example, you might ask software suppliers to complete NCSC’s assurance principles and claims assessment, or enhance your existing due diligence processes for software suppliers to test compliance against the “Achieved” indicators of good practice.
Supporting evidence
To support your response, you can upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. An example is:
- evidence of suppliers’ completion of assurance mechanisms tied to the DSIT / NCSC software security code of practice
- evidence of more specific assurance obtained such as NCSC’s assurance principles and claims assessment
You can provide other types of evidence if you feel they are relevant to the contributing outcome.
Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate.
Interpreting indicators of good practice
| Indicator(s) of good practice | Term | Interpretation |
|
PA#1 Your software supplier leverages secure development principles and practices. |
'software supplier' | Where your organisation develops software in-house, your internal software development team effectively becomes the “software supplier” referred to in the indicators of good practice for this outcome. |
Additional guidance
For additional guidance, see:
National Cyber Security Centre CAF guidance | A4 Supply chain
National Cyber Security Centre | Software security code of practice
Last edited: 26 August 2026 11:59 am