Notify first the customers who run an affected version in a deployment that is exposed or hard to patch, then other affected customers, then everyone else with a short status. Tiering by exposure gets action to where it matters while still reaching every account on the same day.
Why order matters
A notice goes to many people, but attention is limited. A customer running an affected, internet-facing deployment needs to read the notice in the first hour. A customer with no affected product needs a one-line confirmation. Treating them the same slows the first group and floods the second.
You can only tier if you know who runs what. For SaaS products that is usually in your own deployment records. For software customers host themselves, you may rely on licence or download records, support tickets and telemetry where it exists. Where you do not know, say so and place those customers in the broadest affected tier until you learn more.
A tier model
| Tier | Who | Channel | Message |
|---|---|---|---|
| 1 | Affected version, exposed or high impact deployment | Direct contact from a named person | What to do now, how to reach you |
| 2 | Affected version, lower exposure | Email and support portal | Upgrade or mitigation steps |
| 3 | Unknown version or deployment | Email plus a self check guide | How to tell whether they are affected |
| 4 | Not affected | Short status page entry | Confirmation, no action needed |
Steps
- Take the hit list from your SBOM search (see finding every product that ships a vulnerable component).
- Map each affected product and release to customers using your own records.
- Mark exposure: is the component reachable from outside, does it process untrusted input, is the deployment in a regulated setting?
- Assign tiers and a sender for Tier 1, so each key account hears from a person.
- Send in tier order, but within the same working day where possible.
- Log who was sent what and when.
Be careful with the not affected group
Telling a customer they are not affected is a statement of fact, so it needs the same evidence as any VEX statement. The CISA minimum requirements say a not affected statement needs a justification or an impact statement. If you cannot provide one yet, place that product under investigation rather than telling customers it is clear.
Contracts and regulation
Some customers have contractual notice terms or sector rules with fixed timelines. This post does not interpret any of them. Ask your counsel which customers need a formal notice and by when, and add those to Tier 1 regardless of exposure.
Quick check
Do we need one message or several?
Same facts, different framing. Keep the core status lines identical so nobody receives conflicting information.
What if we do not know who runs which version?
Say so, give a simple way to check, and treat those customers as potentially affected until you know more.
Safeguard's asset discovery and SBOM tooling can help you maintain the inventory that makes tiering possible.
Sources
Last reviewed: 19 October 2026.
