Tell schools what you know, what you do not, what you are doing, and what they should do, in that order, in plain words. Do not wait for perfect answers. Send a short first notice, then updates on a stated rhythm. Ask counsel about any contractual or legal notice duties. This is not legal advice.
First decide whether it needs a notice
Not every vulnerable library needs a customer message. A useful triage:
| Question | If yes |
|---|---|
| Is the vulnerable code present in what customers run? | Continue |
| Can it be reached through your app in a way an attacker could use? | Raise priority |
| Is there evidence of exploitation or exposed student data? | Treat as an incident and follow your incident plan |
| Do customers need to act, such as updating a client app? | Notify with instructions |
A vulnerability found and fixed before anyone could reach it often belongs in release notes, not an alert. Be consistent so customers know what to expect from you.
What the first message should contain
- What happened, in one sentence. Name the component and the type of issue.
- Who is affected. Which products and versions, which customers.
- What you know about data. Say whether you have evidence of access to student data. If you do not know yet, say that, and say when you expect to know.
- What you are doing. Patching, mitigating, investigating.
- What they should do. Update an app, rotate a credential, nothing yet.
- When you will write next. A specific time.
- A real contact. A monitored address and a person.
What to avoid
- Guessing. If you do not know, say so.
- Blaming the open source maintainer. Schools care about what you will do.
- Jargon without explanation. Many recipients are administrators and teachers, not security staff.
- Absolutes such as "no data was affected" before you have proven it.
- Silence while you wait for a full report.
Prepare before you need it
Write the template now, in calm conditions. Keep a contact list for each district, including technology directors and privacy officers. Agree internally who approves outside messages. CISA's materials stress that many schools have limited technology staff, so clear, specific instructions help more than long technical details.
Keep an inventory so you can answer the first question quickly. If you must spend two days finding out whether a library is in your product, your notice will be late.
After the notice
Publish a short follow up when the fix ships, including what changed and what customers should verify. Keep a record of timelines for your own review, and run a short retrospective: how did the flaw get in, how did we find it, what would have caught it earlier?
Try it yourself
Open the demo and walk through how exploitability is judged. The same reasoning feeds the "who is affected" line of your first message.
Click through it at your own pace, or open it full screen.
Safeguard's reachability analysis and SBOM help answer whether a flawed component is present and used, and the free scan gives a first look.
Quick check
Should we notify before we have a fix?
If customers can take protective steps, or if student data may be at risk, early notice is often better. Your counsel and contracts will set minimum duties.
Who in the school should receive it?
Usually the technology lead and the privacy contact named in your agreement, with a copy to the account owner.
Sources
Last reviewed: 19 October 2026.
