The short answer
Supply chain security is the work of protecting your organisation from risks that enter through suppliers, service providers and the software and components you depend on. It means knowing who your suppliers are, setting minimum security requirements, building them into contracts, checking they are met, and controlling software dependencies and build pipelines. The NCSC's 12 principles are the UK reference.
On this page
- What is supply chain security?
- What is a supply chain attack?
- What are the NCSC’s 12 supply chain security principles?
- How do you secure your software supply chain?
- Is Cyber Essentials a supplier requirement?
- What do PCI DSS and ISO 27001 require for supply chain security?
- How should a small team start?
- Why Sovereign Secure
- Need supplier evidence or a code review?
Supply chain security protects your organisation from risks that come in through the organisations and software you depend on: IT and managed service providers, cloud and SaaS platforms, payroll and payment processors, and the commercial and open-source code inside your own systems. Attackers target suppliers because one compromise can reach many customers, so part of your security now depends on theirs.
This guide covers how supply chain attacks work, the NCSC’s 12 principles, software supply chain controls, and what PCI DSS and ISO 27001 require. The governance programme around it, from supplier inventory to contracts and exit, is covered in our guide to third party risk management.
What is supply chain security?
Supply chain security is the set of controls that limit the harm a supplier, product or component can do to you if it is compromised or fails. It covers three layers:
| Layer | Examples | Risk |
|---|---|---|
| Service suppliers | MSPs, cloud and SaaS providers, payroll, payment and file-transfer services | A breach at the supplier exposes your data, or its access to your systems is used against you |
| Software | Commercial software and its updates, open-source libraries, build tools, third-party scripts on your website | Malicious code arrives inside a trusted update or dependency |
| Hardware and components | Network equipment, payment terminals, IoT devices and their firmware | Tampered or vulnerable components enter your estate |
What is a supply chain attack?
A supply chain attack is one where the attacker compromises a trusted supplier, product or component in order to reach that supplier’s customers. These supply chain attack examples, all public incidents, show the main routes:
| Incident | How it worked | Lesson |
|---|---|---|
| SolarWinds Orion (2020) | Malicious code inserted into the build process of a network monitoring product reached customers through normal signed updates | A signed update isn’t proof of a safe one; protect build pipelines |
| Kaseya VSA (2021) | Ransomware was pushed through a remote monitoring and management tool used by MSPs, reaching their customers | IT provider access is privileged access; limit and monitor it |
| Log4Shell (2021) | A critical flaw in Log4j, a widely used open-source Java logging library, exposed many applications at once | You can only patch what you know you run |
| MOVEit Transfer (2023) | A zero-day flaw in a file-transfer product was used to steal data from its users, including UK employers’ staff data held by a payroll provider | Your suppliers’ suppliers handle your data too |
| Synnovis (2024) | Ransomware at a pathology services provider disrupted blood tests at NHS hospitals in south east London | Operational dependence on a supplier is a security risk |
Package registries are a growing target. The NCSC’s June 2026 post on software supply chain attacks describes attackers stealing developer tokens to publish malicious versions of trusted packages, which automated pipelines then pick up.
What are the NCSC’s 12 supply chain security principles?
The NCSC groups its supply chain security principles into four stages: understand the risks (1 to 3), establish control (4 to 9), check your arrangements (10) and continuous improvement (11 and 12). They are guidance, not law, and a small organisation can apply them in proportion to the suppliers it has.
| Principle | In practice |
|---|---|
| 1. Understand what needs to be protected and why | Identify the data, systems and services that matter most |
| 2. Know who your suppliers are and build an understanding of what their security looks like | A supplier list showing what each one can access |
| 3. Understand the security risk posed by your supply chain | Rate suppliers by access, data and how hard they are to replace |
| 4. Communicate your view of security needs to your suppliers | Tell suppliers what you expect and why |
| 5. Set and communicate minimum security requirements for your suppliers | For example, Cyber Essentials for any supplier handling your data |
| 6. Build security considerations into your contracting processes and require that your suppliers do the same | Security, incident notice and audit clauses, passed down to subcontractors |
| 7. Meet your own security responsibilities as a supplier and consumer | Meet the standard you ask of others |
| 8. Raise awareness of security within your supply chain | Share guidance and expectations with suppliers |
| 9. Provide support for security incidents | Agree how you and suppliers notify and help each other |
| 10. Build assurance activities into your supply chain management | Check evidence, certificates and test results, not just answers |
| 11. Encourage the continuous improvement of security within your supply chain | Raise requirements as suppliers mature |
| 12. Build trust with suppliers | Relationships where problems are shared early |
How do you secure your software supply chain?
Software supply chain security means knowing what code you run, where it came from and that nobody tampered with it. The main controls:
| Control | What it involves |
|---|---|
| Inventory and SBOM | A list of every component and dependency; for software you build or sell, a software bill of materials (SBOM) in a standard format such as SPDX or CycloneDX |
| Dependency review | Scan dependencies for known vulnerabilities, keep them few, and review new versions before adopting them, while still applying security fixes quickly |
| Developer and registry accounts | MFA on source code repositories, package registries and CI/CD accounts; rotate tokens and secrets straight away if exposed |
| Controlled build pipelines | Deploy only through a controlled pipeline, not from developer laptops; restrict who can change it and monitor its activity |
| Integrity checks | Sign releases, verify signatures and checksums, and use trusted or private registries where appropriate |
| Code review and testing | Review your own code, and how it uses third-party components, before release |
If you sell software, the UK government’s Software Security Code of Practice, published in May 2025 and developed with the NCSC, sets out 14 principles vendors are expected to follow, including protecting their build environments. Cyber Essentials v3.3 now refers to it. Products with digital elements sold in the EU face SBOM and vulnerability handling duties under the EU Cyber Resilience Act: its reporting obligations have applied since 11 September 2026, and the rest applies from 11 December 2027. Our secure source code review checks your code and its use of third-party components.
Is Cyber Essentials a supplier requirement?
Often, yes. Under Procurement Policy Note 014, UK central government departments, their executive agencies, non-departmental public bodies and NHS bodies must make sure suppliers meet the Cyber Essentials technical requirements on in-scope contracts, such as those handling citizens’ or government staff’s personal information, and many private buyers ask the same of their suppliers. Our guide to whether Cyber Essentials is mandatory sets out the rules.
Used as the minimum requirement under principle 5, Cyber Essentials certification is assessed by a licensed certification body, valid for 12 months and quick to verify. When you certify yourself, v3.3 also brings supplier access inside your scope:
- All accounts your organisation owns are in scope, even when a supplier, contractor or MSP uses them to manage your systems.
- If you use externally managed services such as remote administration, you must be able to confirm the controls are met.
- Where a cloud provider implements a control for you, it must have committed to it in the contract or in documents the contract references, such as security statements.
Cyber Essentials is a baseline, not full assurance, so ask higher-risk suppliers for more. Our vendor risk assessment guide lists the evidence to request.
What do PCI DSS and ISO 27001 require for supply chain security?
Both standards have supplier governance controls: PCI DSS Requirement 12.8 (a provider list, written agreements, due diligence and annual monitoring) and ISO/IEC 27001:2022 Annex A 5.19, 5.20 and 5.22. Our third-party risk management guide covers those, along with DORA and UK financial rules, and our NIS2 guide explains how the EU directive’s supply chain duty (Article 21) reaches UK suppliers through contracts. The CIS Controls cover the same ground in Control 15, Service Provider Management, and the UK Cyber Security and Resilience Bill would let regulators designate critical suppliers to essential services and bring them under the NIS regime. The controls below deal with the technical side: the code, scripts, cloud services and remote access that suppliers bring in.
| Standard | Requirement | What it asks |
|---|---|---|
| PCI DSS v4.0.1 | 6.3.2 | An inventory of bespoke and custom software and the third-party components built into it, to support vulnerability and patch management |
| PCI DSS v4.0.1 | 6.4.3 | Every payment page script loaded and run in the customer’s browser is authorised, has its integrity assured and is listed with a written justification |
| PCI DSS v4.0.1 | 11.6.1 | A change- and tamper-detection mechanism alerts staff to unauthorised changes to the security-impacting HTTP headers and script contents of payment pages as the customer’s browser receives them, at least weekly or at a frequency set by targeted risk analysis |
| PCI DSS v4.0.1 | 8.2.7 | Accounts third parties use for remote access are enabled only when needed, disabled when not in use, and monitored |
| ISO/IEC 27001:2022 | Annex A 5.21 | Processes to manage the security risks of the ICT products and services supply chain |
| ISO/IEC 27001:2022 | Annex A 5.23 | Processes for acquiring, using, managing and exiting cloud services |
| ISO/IEC 27001:2022 | Annex A 8.30 | Directing, monitoring and reviewing outsourced system development |
Requirements 6.3.2, 6.4.3 and 11.6.1 have been mandatory since 31 March 2025. The last two are aimed at e-commerce skimming code added to payment pages, often through a compromised third-party script.
How should a small team start?
Six steps you can take this quarter:
- List suppliers that hold your data or reach your systems, starting with your IT provider, cloud services and payroll.
- Lock down supplier access. Named accounts, MFA, and remote access enabled only when needed.
- Set a minimum requirement, such as Cyber Essentials for any supplier handling your data, and check each certificate is current.
- Inventory your software: what you run, its versions and, if you build software, its dependencies.
- Protect developer accounts with MFA on code repositories, package registries and build pipelines.
- Plan for supplier failure. For each critical supplier, know how you would keep working if it went down.
Why Sovereign Secure
Where we help is the evidence on both sides of the supplier relationship:
- Cyber Essentials certification. As an IASME-licensed certification body, we issue the Cyber Essentials and Cyber Essentials Plus certificates many buyers require from suppliers.
- PCI DSS assessments. We are a PCI SSC Qualified Security Assessor (QSA) company, Qualified PIN Assessor and Card Production Security Assessor, and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028.
- ISO 27001 consultancy. We are ISO 27001 certified, and our consultancy covers supplier controls 5.19 to 5.23. Certification audits are carried out by our partner certification body, MQA International.
- Testing. Source code review, penetration testing (including hardware and IoT) and vulnerability scanning, with external ASV scans delivered through a PCI SSC Approved Scanning Vendor partner.
Sovereign Secure Ltd was founded in 2012, with its head office in Accrington, Lancashire, and offices in Los Angeles, Singapore, Dubai and Dhaka.
Need supplier evidence or a code review?
If a customer has asked you for a Cyber Essentials certificate, an Attestation of Compliance or a security test, or you want your code and dependencies reviewed, get in touch or call +44 161 523 5276.
Your next step
- ISO 27001 checklistClause-by-clause readiness and a Stage 1 and Stage 2 audit checklist, free in Excel.Get the checklist
- Statement of Applicability templateAll 93 Annex A controls in a free spreadsheet, with a worked example.Get the SoA template
- Get an ISO quoteConsultancy from an ISO 27001-certified firm, with audits through our partner certification body, MQA International.Get an ISO quote
Last reviewed October 2026 by the Sovereign Secure assessment team.




