Tech suppliers need to pass new security baseline down the supply chain

Customers in regulated sectors have long required tech suppliers to pass security obligations on to their subcontractors and sub-processors. What has changed is that many tech businesses are now regulated in their own right, and most have taken on new customer commitments through EU Digital Operational Resilience Act (DORA) remediation, Network and Information Security Directive 2 (NIS2) compliance programmes or preparation for the EU Cyber Resilience Act (CRA).

Since 11 September 2026, manufacturers of hardware and software products placed on the EU market have had to report actively exploited vulnerabilities and severe incidents under the CRA. The CRA's main security requirements apply from 11 December 2027.

NIS2 brings cloud, data centre, managed service and managed security service providers, among others, within national cybersecurity laws.

DORA applies directly to the 19 ICT providers that EU financial supervisors designated as critical in November 2025.

DORA also impacts every other provider of ICT services to EU financial entities, through the contract terms those entities must impose. UK businesses are also within scope of these regimes when they sell into the EU or support EU regulated customers and face additional UK rules described below.

As a result, a tech supplier is answerable to both its customers and regulators, which expect it to meet defined security standards. Its ability to do so, however, depends on vendors whose contracts often predate those standards. Where a supplier has promised its customer, or owes its regulator, more than its vendors have promised it, the supplier bears the shortfall risk.

Why existing vendor terms fall short

Many vendor contracts rely on a promise of industry standard security, the vendor's own security policies, ISO/IEC 27001 certification, a data processing agreement, or a general obligation to comply with applicable law. Each of these has a specific limitation.

Industry standard wording and the vendor's own policies leave it to the vendor to decide what is enough. ISO/IEC 27001 certification demonstrates that the vendor runs an information security management system within the scope stated on the certificate, but it does not determine which controls apply to a particular service or component.

A data processing agreement covers the security of personal data, not the availability of a service or the security of a product.

A simple obligation to comply with law requires little as the vendor may correctly say that DORA and NIS2 do not apply to it and that CRA obligations rest with the manufacturer of the finished product.

Suppliers need information, controls and assistance that enable them to meet the obligations that apply directly to them and to their customers. Vendor contracts therefore need to be drafted to secure these commitments.

Security expectations on vendors

NIS2 requires in-scope entities to take appropriate and proportionate security measures covering 10 specified areas, one of which is supply chain security. Entities must take account of each direct supplier's vulnerabilities and of the quality of its products and security practices, including its secure development.

A supplement to NIS2, Implementing Regulation (EU) 2024/2690, sets out the detail for cloud, data centre, managed service and other digital providers. It applies directly only to those providers, but it is the most useful benchmark for other technology businesses.

The implementing rules require contracts with suppliers to set out, where appropriate, the cybersecurity requirements the supplier must meet, including specific requirements for buying ICT products and services. Those requirements cover security updates for the life of the product or service, information about its hardware and software components, its security functions and secure configuration, assurance that it meets the security requirements, and methods for validating that it does.

Where development is outsourced, the entity's secure development rules apply to the developer. Those rules cover every stage from specification and design through to testing.

The CRA makes the manufacturer responsible for the security of the whole product. Manufacturers must exercise due diligence when integrating third party components, including open source software, so that those components do not compromise the product's security.

The finished product must meet essential requirements that depend heavily on its components, including having no known exploitable vulnerabilities, secure default settings, the ability to receive security updates and protection of data and functions. Manufacturers must also handle vulnerabilities for a support period of at least five years, unless the product is expected to be in use for less.

A component vendor that stops supporting its component does not bring the manufacturer's obligation to an end. Components bought now will be built into products sold after December 2027, so their contracts need CRA terms already.

DORA primarily impacts technology suppliers through their financial services customers. Like with the NIS2 implementing regulation, Delegated Regulation (EU) 2025/532 supplements DORA. It requires the financial entity's contract with its ICT provider to oblige the provider to ensure that its subcontracts for services supporting critical or important functions contain business contingency requirements and service levels, specify ICT security standards and give the financial entity and its regulators the same rights of access, inspection and audit.

Consider a supplier that signs a DORA addendum making these promises while its own cloud or software provider remains on its original terms. That supplier has made a promise it cannot enforce against its own provider.

The UK position

The UK addresses the same issue through several regimes. The Network and Information Systems Regulations 2018 require operators of essential services and certain digital service providers to manage security risks, and regulators assess compliance using the National Cyber Security Centre's cyber assessment framework, which includes a supply chain principle.

The Cyber Security and Resilience Bill will bring managed service providers and data centres into scope and allow critical suppliers to be designated. The Bill is in the House of Lords, with Royal Assent expected between late 2026 and spring 2027.

In financial services, the Prudential Regulation Authority’s SS2/21 and the Financial Conduct Authority's SYSC 8, which both deal with outsourcing, require firms to address security, continuity, audit and sub-outsourcing in material arrangements. New rules on reporting operational incidents and material third-party arrangements apply from 18 March 2027.

The UK Treasury's first designations under the ‘critical third parties’ regime took effect on 13 July 2026, covering Amazon Web Services EMEA Sarl, Google Cloud EMEA Limited, Microsoft Ireland Operations Ltd and Oracle Corporation UK Limited. Designated providers must manage the risks in their own supply chains.

For products, the UK’s Product Security and Telecommunications Infrastructure (PSTI) regime applies only to consumer connectable products. For business software, the nearest UK benchmark is the voluntary Software Security Code of Practice, which sets out 14 principles that cover secure design and development, build environment security, secure deployment and maintenance, and communication with customers.

Building a baseline that works

Separate vendor schedules for each regime produce overlap and inconsistency. A single baseline organised under the 10 NIS2 headings also covers what DORA and the UK NCSC’s cyber assessment framework require.

Component and software vendors need an additional product security schedule built on the CRA requirements. Referring to recognised standards shortens negotiation because most vendors already work to them, and the NIS2 Implementing Regulation itself lists ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319 401.

The baseline should not reproduce the regulations. Instead, it should turn the obligations that depend on the vendor into requirements that can be measured and enforced. A schedule meets that test only if it answers questions such as how quickly a critical vulnerability must be fixed, how long security updates will be provided, which components are used, what evidence shows compliance and which requirements pass to the vendor's own subcontractors.

Prioritise, and document what cannot be fixed

Remediating every contract at once is rarely realistic. Suppliers should start with vendors of components or code built into their products, providers whose failure would disrupt their services, vendors with privileged access to systems or data, and subcontractors supporting services that customers have classed as critical or important.

A standard addendum can be used for those vendors, with others updated at renewal. Where a vendor will not agree a term, the supplier should record the gap, the alternative evidence or controls it relies on, and who accepted the remaining risk.

That approach has a legal basis as the NIS2 Implementing Regulation's contract requirements apply "where appropriate", and regulators generally expect entities to document their reasoning where a requirement is not appropriate or feasible. A documented, reasoned gap can be defended, but a gap nobody identified cannot.

Where vendors push back

Large cloud and platform providers will rarely sign a customer's schedule. Suppliers should compare those providers' standard terms, regulatory addenda and independent assurance reports against the baseline, accept them where they are equivalent and record the gaps.

While practical, outcome-based wording is usually preferred to compliance with prescriptive controls, this is not always acceptable to all regulators. A workable position therefore is to include outcome-based obligations tied to a named standard, plus a short list of mandatory controls that the supplier's own customers or regulators require.

Vendors will not agree to follow a customer policy "as updated from time to time". The current version should be attached, with change control for ordinary updates and a separate mechanism for changes the law requires.

Component vendors resist open-ended commitments to provide security updates for a product's entire lifetime. Suppliers should seek a defined support period matched to their own, at least 24 months' notice of end of life for long life products, a last time buy right, and source code escrow or a licence to maintain the component if support stops early.

Vendors often object to disclosing the components in their products on confidentiality or security grounds. Disclosure can be limited to what compliance requires, protected by confidentiality and shared with regulators only where necessary.

Vendors will not give an absolute warranty that a product has no known exploitable vulnerabilities. A reasonable compromise is a warranty covering vulnerabilities the vendor knows of or would find by applying a stated testing standard before delivery, together with fixed timescales for remediation.

Major providers often have difficulty committing to third party system testing programmes. The contract should, in many cases where still consistent with the regulatory requirements, specify which independent reports, test summaries or pooled tests will be provided instead, and when.

Vendors also resist responsibility for their own subcontractors. In many circumstances, the appropriate position will be that protections pass down in proportion to each subcontractor's role, with the vendor remaining responsible for the services it has agreed to provide.

Vendors will ask to be paid for compliance. Many are themselves NIS2 entities or CRA manufacturers and must already do most of this, so the case for extra charges is strong only where the customer asks for more than the law requires.

Negotiations often stall on liability. Under English law, a business generally cannot recover from a vendor a regulatory fine imposed for its own breach. As such, the negotiation should focus on the losses that flow from the vendor's breach.

Tech suppliers that have taken on DORA, NIS2, CRA or UK resilience commitments should check whether their vendor contracts, service documentation and assurance rights allow them to meet those commitments. Those that do so now can fix their highest risk arrangements in a planned programme, rather than finding the gap during a customer audit, a conformity assessment, an incident or a regulator's enquiry.