A first year security program should add three kinds of clauses to vendor contracts: notice of security incidents, notice of confirmed vulnerabilities, and stated security requirements used in selection. Begin with vendors that hold customer data or reach production, and set the notice window to a time frame you can act on.
Where these ideas come from
CISA's Cybersecurity Performance Goals describe three supply chain outcomes in procurement terms. Contracts and SLAs should stipulate that vendors notify the customer of security incidents within a risk informed time frame, and of confirmed security vulnerabilities in their assets within a risk informed time frame. Procurement documents should include cybersecurity requirements and questions that count in vendor selection, so that of two similar offers the more secure supplier is preferred. (The CISA page is archived and points to a newer version, so check the current list.)
Notice that the goals leave the time frame to each organization. That is right: the useful window is the one your team can respond within.
The clauses
| Clause | What it says in plain words | Why it matters |
|---|---|---|
| Incident notice | The vendor tells you when an incident may affect your data or service, within an agreed time | Starts your own response clock |
| Vulnerability notice | The vendor tells you about confirmed vulnerabilities in what they provide | Lets you patch or mitigate |
| Security requirements | Baseline expectations, such as multi-factor sign-in for admin accounts and encryption of your data | Gives you grounds to ask for fixes |
| Contact and escalation | Named security contact and an escalation path | Saves hours in a real incident |
| Subprocessors | Notice when the vendor adds a subprocessor that handles your data | Keeps your own list accurate |
| Exit | How you get data back and how it is removed | Avoids lock in surprises |
Have your lawyer review the wording. This table describes intent, not legal text.
How to roll it out
- List vendors with access to customer data or production, and rank them.
- Start with new contracts and renewals. Rewriting every contract at once is rarely realistic.
- Prepare standard wording once, with your counsel, and reuse it.
- Ask for security documents the vendor normally shares, and record what you received.
- Name an internal owner for each vendor relationship.
- Review the list every quarter.
What to do when a vendor pushes back
Large vendors often will not change terms for a small customer. In that case record what they do offer, such as a public trust page and a notice process, accept the residual risk consciously, and record that decision with the owner's name. For a critical vendor with weak terms, add a note to the roadmap to review alternatives.
Do the same for your own customers
Your buyers will ask you for the same clauses. Think through what you can promise before you are asked: which time frame, who sends the notice, and how. The answers form part of your customer security summary.
Pitfalls
- Setting a notice window too short to meet yourself.
- Collecting questionnaires without reading them.
- Treating a vendor's audit report as a blanket assurance, when its scope may not cover the service you use.
Safeguard's SBOM and dependency scanning helps with the software supply chain side of vendor risk, and compliance and evidence automation helps keep vendor records. Try the free scan.
Quick check
How fast should a vendor have to notify us?
Choose a window you can act on and can honor for your own customers. CISA leaves it to each organization.
Do we need these clauses for every vendor?
Start with vendors that hold customer data or access production, then widen as capacity allows.
Sources
- CISA Cybersecurity Performance Goals (archived page that points to a newer version)
Last reviewed: 19 October 2026.
