How it is created — CON-CLS-007 Supplier Security Clause Set

1. Why this artifact exists

The CRA makes you responsible for every component you ship, including the ones you did not write and cannot see inside. Technical evaluation catches the components that are bad today. It cannot catch the supplier who stops patching in year four, or who learns of a vulnerability in March and mentions it in an October release note.

Those are contract problems, and they can only be fixed at purchase time. Once the component is designed into the hardware, your negotiating position is gone — you are asking for a favour rather than agreeing a term, and the answer is usually a link to a public advisory feed.

So the clause set exists to be handed to Purchasing before the component is chosen, as a condition of selection rather than a wish afterwards. A supplier who refuses it has told you something useful while it is still cheap to hear.

2. Inputs

• Your component policy — the technical knock-out criteria the clauses have to backstop.
• The [declared support period](/resources/examples/sdl-std-022) of the products the component will go into, plus your margin. This is the number that sets the contractual patch term, and it is the one most often left out of the contract.
• Your EOL check, which tells you which components already have a supportability problem a contract could cure.
• The vulnerability handling process, so the notification clause lands in a channel someone monitors.
• Your legal template set, so the clauses can be attached to a purchase contract without a bespoke negotiation each time.

3. Steps

1. Start from the three failure modes, not from a checklist: no notice, no patches, no fallback. Every clause should be traceable to one of them; a clause that is traceable to none of them is padding that costs you negotiating capital.
2. Write the notification clause with a number in it. "Without undue delay" is what you owe your customers; what you need from a supplier is a deadline — 72 hours from their awareness — because your own regulatory clock starts when you find out.
3. Make the patch term an absolute date. Support period plus your margin, written as a year, not "for the life of the product". Both parties will read "life of the product" differently, and they will do it during an incident.
4. Set the EOL notice long enough to migrate. Twenty-four months sounds generous until you cost a stack migration on an embedded product; it is roughly one maintenance release plus the slack to qualify it.
5. Require the SBOM per release, with identifiers and hashes. Without it, a binary component is a hole in your own SBOM, and your CVE matching silently stops at its boundary.
6. Get source or escrow, and define what releases the escrow. Insolvency, discontinuation, and failure to patch within your own remediation deadlines. The third condition is the one that gets omitted and the one you will actually invoke.
7. Claim the right to fix and to ship the fix. Escrow without a licence to distribute a corrected build to your customers gets you source code and no remedy.
8. State that regulatory reporting overrides confidentiality. Otherwise an NDA and Art. 14 will eventually point in opposite directions, and the contract will be the reason you missed a deadline.
9. Flow the terms down to subcontractors, and keep one point of contact. A supplier who integrates someone else's stack has not thereby transferred your problem to a party you have no contract with.
10. Define the deviation path before you need it. Two signatures, a compensating measure, and a date — otherwise the first hard negotiation becomes an undocumented exception.

4. Done when

• Every clause traces to notice, patches, or fallback.
• The notification clause names hours; the patch clause names a date; the EOL clause names months.
• Escrow release conditions include the supplier's failure to meet your own remediation timelines.
• The clause set survives contract termination for as long as the products are in support.
• Purchasing cannot sign a component contract without security sign-off.
• There is a written deviation path with two named approvers.

5. Common mistakes

Writing the clauses after the hardware is chosen. Accepting a public advisory feed as "notification" — it reaches you exactly when it reaches attackers. Tying the patch term to the contract term rather than to the product's support period, so support ends while the product is still on sale. Escrow with untested release conditions, which is a filing cabinet, not a fallback. And letting a confidentiality clause outrank a reporting obligation.

6. In TRA Studio

Component obligations are where requirement coverage quietly breaks: the requirement is assigned, the activity exists, and the evidence depends on a third party who never agreed to produce it. When you assign the component due-diligence requirements to activities in your Secure Lifecycle, check what each one's evidence actually depends on. If the answer is a supplier, the contract is part of your conformity argument, and a requirement whose evidence nobody has contracted for is a gap wearing a green checkmark.