Support agents can say what is confirmed, what you are doing, and where to find updates. They should not guess at cause, scope, attribution or impact. Prepare a short script, a list of approved facts that changes as the incident does, and a single escalation path for anything outside the script.
Why support needs its own script
Customers write to support first. Engineers are busy, and security leaders are in meetings. An agent who improvises under pressure may speculate, or may contradict a statement the company has not published yet. A prepared script protects customers and agents.
The three layers of an answer
- Confirmed facts. What the company has verified and approved to share.
- What you are doing. Actions underway, with no promise of timing unless approved.
- What the customer can do. Steps within their control.
Anything outside these layers is deferred and escalated.
Sample wording
Adjust these for your voice and have the approving owner review them.
| Customer asks | Reasonable response |
|---|---|
| "Are you affected?" | "We are investigating a reported issue in an open source component. We will share confirmed information at [update page] as soon as we have it." |
| "Was my data accessed?" | "We have not confirmed that at this time. We will update this page and contact affected customers directly if that changes." |
| "Should I change my password or keys?" | "If you have not heard from us, no action is needed on your side yet. If we advise action, we will say exactly what to do." Adapt this to the facts as approved. |
| "Who did this?" | "We do not speculate about cause or who is responsible. We will share verified details when we have them." |
| "When will it be fixed?" | "Our engineers are working on it. We will post updates at [update page]." |
Avoid reassurance you cannot back, such as "nothing to worry about." Avoid detail you have not confirmed, such as the number of customers affected.
Words to avoid
Skip "breach" and "no impact" unless the owner of external statements has approved them. Also avoid naming individuals or suppliers. The guide on incident or outage wording in customer messages covers word choice.
Escalation path
Name one channel, one person per shift, and one response time target. Agents tag each case with the same label, so the team can count volume and spot patterns. Questions outside the script go to the named person, who answers or routes them to security, legal or communications.
| Case type | Route |
|---|---|
| Customer wants technical details | Security liaison |
| Customer cites a contract or notice clause | Account owner and counsel |
| Journalist or analyst | Communications lead only |
| Customer reports suspicious activity | Security liaison, with the case preserved |
Keeping the script true
Review the approved facts at fixed times during the incident, for example every two hours. Date every version. Retire old versions so agents do not use stale text. After the incident, review the tagged cases to improve the next script.
Practice it
Run a ten minute support drill in a tabletop: read five realistic customer messages and have agents answer from the script. Gaps show up quickly. This guide gives no legal advice, so have counsel review wording before use.
Quick check
Should agents tell customers to rotate credentials?
When the company has approved that advice, and not before. Premature advice causes confusion and may be wrong.
Who approves the support script?
The owner of external statements, with security and legal input, before an incident when possible.
Safeguard can help with the inventory side of this work. SBOM and dependency scanning show where a package and version appear across your projects, and policies and gates can stop a flagged version at the pull request. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
