CAF supply chain: how to meet principle A4
CAF principle A4 expects you to understand and manage supplier risk, know your sub-contractors and third-party connections, and put security obligations in relevant contracts. CAF 4.0 adds secure software, which matters more as the Cyber Security and Resilience Bill (CSRB) brings supply chains into focus.
The Bill is not yet law. Regulation and section references come from the Bill as brought from the Commons (HL Bill 32). The Lords has since amended the Bill, so numbering and detail may change in the final Act. This guide is general information, not legal advice.
Where supply chain sits in the CAF
Principle A4 of the Cyber Assessment Framework (CAF) covers risks that come from depending on suppliers. It matters more under the Cyber Security and Resilience Bill (CSRB), which brings managed service providers and data centres into regulation and lets regulators designate critical suppliers.
In CAF 4.0, A4 has two outcomes:
- A4.a Supply Chain: understanding and managing the risks suppliers pose to the systems behind your essential functions.
- A4.b Secure Software Development and Support: maximising the use of secure and supported software, whether developed internally or sourced externally. This outcome is new in version 4.0.
What each rating looks like for A4.a
| Rating | In short |
|---|---|
| Not achieved | You don't know what data suppliers hold, can't see sub-contractors, don't know which contracts matter, or suppliers have unrestricted or unmonitored access |
| Partially achieved | You know the extent of your supply chain including sub-contractors, you're aware of all third-party connections with assurance they meet your requirements, and relevant contracts include security obligations |
| Achieved | You understand the chain deeply, weigh factors such as supplier ownership and nationality, consider supply chain subversion by capable attackers, and actively manage contracts with defined responsibilities |
The jump to "achieved" is significant. It assumes capable and well-resourced attackers, not just common threats, and that may not be the right target for every organisation. A regulator's profile, where there is one, should settle that.
Five questions to answer first
- Which suppliers support your essential functions? Start from the function and work outward, not from the procurement list.
- Who are their sub-contractors? The CAF treats "little or no visibility" as a not-achieved indicator where parts of the chain are subcontracted.
- Who can connect to your systems, and how? Include remote support tools, service accounts and APIs. Access that bypasses your controls or goes unmonitored is another not-achieved indicator.
- What data do they hold? Be able to say what it is and how it's managed.
- What happens in an incident? Your process and theirs should support each other, and you should know how they'll tell you.
What to put in contracts
The CAF expects appropriate security obligations in relevant contracts, and customer and supplier responsibilities to be defined. It doesn't give standard clauses. Consider covering:
- minimum security standards and a right to evidence or audit
- notification of incidents, with a timescale that supports your own reporting
- sub-contractor approval or disclosure
- limits on access, and monitoring of that access
- patching and security update commitments
- data location, return and deletion at exit
- co-operation with you, and with regulators where relevant
If you're regulated, a supplier incident can start your own reporting duties. The Bill requires a full notification to include details where an incident was caused by a separate incident at another regulated person, so you'll need that information quickly.
Asking software suppliers the right questions
A4.b turns software security into a supplier conversation. Useful questions based on the indicators:
- Which secure development framework do you follow? The CAF names NIST SSDF and Microsoft SDL as examples.
- Can you show the composition and provenance of your software, including third-party components?
- How do you monitor those components for new vulnerabilities?
- How are updates tested and delivered, and can we verify their authenticity?
- How will you notify us of significant events?
Open-source software isn't exempt. You should take proportionate steps to build confidence in it, and have suitable support and maintenance arrangements.
CAF "critical suppliers" and designated critical suppliers
The two terms are easy to confuse. In CAF A4.a, "critical suppliers" describes suppliers that are important to your systems, as you judge them. Under the Bill, a critical supplier is a person a regulator has formally designated under regulation 14H, after a process that includes notice and a chance to make representations.
A supplier can matter a lot to you without being designated. Designation also doesn't replace your duty to manage the risk. See our critical suppliers page.
A practical starting plan
- Build a register of suppliers tied to each essential function.
- Rank them by impact and how easily you could replace them. The Bill's designation test also looks at alternative sources.
- Review third-party connections and remove what isn't needed.
- Update contract templates, then apply them at renewal, starting with the highest-risk suppliers.
- Exercise a supplier-caused incident at least once.
- Feed the results into your CAF self-assessment.
The NCSC's supply chain guidance sets out 12 principles and is a good companion to this work.
Sources
Frequently asked questions
Principle A4 covers supply chain risk. It has two outcomes in version 4.0: A4.a Supply Chain and A4.b Secure Software Development and Support.
No. In the CAF it describes suppliers important to your systems. Under the Bill, a critical supplier is a person formally designated by a regulator under regulation 14H.
No. It expects appropriate security obligations in relevant contracts and defined responsibilities, but leaves the wording to you.
Yes. If you use open-source software, you should take appropriate and proportionate steps to build and maintain confidence in its security.