When a client says the feature broke, three sentences are allowed before anyone knows why, and only if you can check them yourself. What they can still do, because you just did it. What you stopped, because you stopped it, and they can see that it is stopped. That you do not yet know the cause. If the first two require a call to the firm that wrote the code, you do not have an incident note. You have a relay. Do not send a cause you have not seen. Do not send a time you have not earned.
This is the note, not the role. Who is allowed to speak to the client, and why the engineer who is fixing it should not be the one who learns the client's voice under load, is a different decision, already made on a calm day or about to be made badly. The content of the first note is this article. A review of the diff before it shipped is a different afternoon again: that is reading a change, not describing a live failure. A late milestone is a schedule. None of those tells the client, tonight, which button still works.
None of what follows is a breach-notification statute, and none of it is legal advice. A personal-data breach can carry a duty to tell a regulator or the people affected, on a clock this article does not start. If you are in that case, call counsel. The note below is the operating message to the client who bought the feature: what is still true, what you have taken out of their hands, and what you are not pretending to know.
Say what is true, to the people who were designated, on a clock you wrote down first. NIST's incident-response profile, SP 800-61 Rev. 3, published 3 April 2025, puts reporting and communication in one category: "Response activities are coordinated with internal and external stakeholders, as required by laws, regulations, or policies." The note under that category splits the work into four, and they are not synonyms. Incident coordination is "communicating current and planned incident response activities" among the people who have roles. Incident notification is "formally informing affected customers, employees, partners, regulators, or others." Public communication is the media. Incident information sharing is voluntary threat information, usually with peers. The recommendation that belongs in the subcontract is the plain one: "Organizations should have mechanisms in place in advance to coordinate with affected parties about incidents when needed" (NIST, SP 800-61 Rev. 3, RS.CO). You are not adopting a federal community profile. You are stealing the split. The client is an affected party. The first email is notification. It is not the analysis, and it is not a post for the trade press.
The procedure names the recipient and the time before the incident, or you do not have one. Under RS.CO-02, the recommendation is to "Follow established procedures concerning incident coordination that include what must be reported to whom and at what times (e.g., initial notification, regular status updates)." A later recommendation on the same row says to notify affected third parties "in accordance with regulatory, legal, and contractual requirements." Under RS.CO-03, share "consistent with the organization's response plans and information sharing agreements, including contracts with suppliers," and "Regularly update senior leadership on the status of major incidents." Read "what must be reported" as a blank you fill on the Tuesday before anything breaks: the client's named recipient, your named sender, and the first interval. "Including contracts with suppliers" is the subcontract. If the only sentence in that contract about incidents is that the partner will use reasonable efforts, you have not filled the blank. You have borrowed theirs. The partner may lead the repair. The note to the client is still yours, because the client's contract is with you.
A third party shows up in a large share of studied breaches, and that share is not your subcontract. Verizon's 2025 Data Breach Investigations Report analysed 22,052 real-world security incidents, of which 12,195 were confirmed data breaches, "the highest number of breaches ever analyzed in a single report," drawn from the Verizon team's case files, contributors, and public incidents. In that set, "the percentages of breaches where a third party was involved doubled, going from 15% to 30%." The later section repeats the finding as "third-party involvement of some sort in 30% of all breaches we analyzed, up from roughly 15% last year." Figure 11, the chart of patterns inside that slice, prints n=2,360. This article does not reconcile 30% of 12,195 with 2,360. They are two presentations in the same report. Use the prose for the share, and do not multiply it into a headcount. The same introduction says the human element "remained roughly the same as last year, hovering around 60%." That is a different fact. A median of 94 days to remediate leaked secrets found in a GitHub repository is a third fact, about a secret sitting in a repository, not about how long you have to send the first note.
Read the definition before you apply the 30% to an agency. The report's own discussion of why it started the metric points at vulnerable software in the supply chain, and it warns that "Not every definition of third-party involvement in breaches would consider the usage of vulnerable software a third-party matter." Elsewhere it separates a partner actor — a supplier, a vendor, a host, outsourced IT, who has to initiate the incident to be the actor — from an attacker who merely uses a partner as a vector. 30% is "of some sort." It is not 30% of breaches were caused by a subcontracted engineering firm, it is not a sample of agencies, and it is not a probability for the engagement you are in. Verizon sells communications and security services. The figure is that report's (Verizon, 2025 Data Breach Investigations Report). What you take from it is the narrower operating point: when someone outside the client's own staff is in the path, the client still needs a note from the party they pay, and a share this wide is a bad excuse for having no sentence ready.
Sentence one: what still works, because you tried it. Open the product with a login the agency administers, or a log the agency can read without asking. Perform the one action the client is most likely to try next — a lookup, a save, a send — and write the result in the words of that action. "Order status still answers. Returns do not." is a sentence you can check. "We are investigating a degradation" is a sentence anyone can send without looking. If the only way to know whether the action works is a message to the partner, you cannot send sentence one yet. Send the fact that you cannot see it, which is a different sentence and an honest one, and fix the login after the incident. The access decision that should have made the login yours — named people, no shared password, production write held back — is what access to give a subcontractor. Tonight you use whatever you already have. You do not invent an observation from their status line.
Sentence two: what you stopped. Name the path you took out of service, in a way the client can confirm. The button is disabled. The job is paused. The send is held for a person. "We are monitoring" is not a stop. A stop is a change in what the next request does, and you should have made it, or watched the partner make it in a system you can see. If you cannot see the stop, do not claim it. Claim the request you have made, and the time you made it. The pre-ship version of the same duty — reading the change before it goes out under your name — is read their change before it ships. An incident is that duty run backwards: something is already out, and the note describes what you have now pulled.
Sentence three: the cause is not known. This is the sentence principals delete because it sounds weak. It is the sentence that keeps the next email true. A cause you have not reproduced is a theory, and a theory copied from the partner's Slack is still a theory, with your name on it. NIST's split is the reason. Notification informs. Analysis is a different category, and it is allowed to arrive later, as an update, when you have a record. "The model hallucinated," "the index is stale," "a bad deploy" — each of those may turn out to be right, and each of them is a lie at 9pm if the only evidence is a guess. Write "cause not established" and the time of the next update. Then keep that time. A missed update teaches the client to call the partner, which is the migration of trust you were trying not to buy. Who holds the microphone, and why putting the repairing engineer on the client call is the expensive shortcut, is who your client trusts when you subcontract. This article only constrains what the microphone is allowed to say.
Four sentences that feel like the note and are not. A root cause. A clock to full repair. An apology that describes an impact you have not measured. And the partner's name, offered so the client knows whom to chase. The partner's name belongs in the disclosure you already made, on a calm day, if the contract required it. It does not belong as the content of an incident, because it answers who, and the client asked what is broken. Impact you have not counted is the same class of invention as a cause. "Some users" is allowed if you have seen some. "All users" is allowed if you have a count. A round number you chose because it sounded serious is not.
The shape of a note that can be checked is ordinary, and it does not require a famous outage. An AI support agent for a DTC ecommerce brand separates order lookups from returns and address changes, with those actions behind permission guardrails, and escalates to a person when confidence is low. An agency that had sold that shape could write, from a login it held: lookups still answer from order data; returns are held; we have not established why the return path failed. That case is a product built under our name. It is not a white-label engagement, and nothing in the description is a headcount, a duration, or a result figure. The shape is the point. Separate actions are separate sentences. A product that only has one action — the model does the thing, or it does not — can still be described, but the first sentence gets shorter: it does not, and here is what the user sees instead.
There is a version of this night where hiring more engineering is the wrong purchase. The work has not been sold, so there is no client to notify and no feature to try. The client asked to meet the builders, and you are still deciding whether to say yes. That is a disclosure decision, not a status note. The room only has a slide, because nothing is in production. A customer of the client has already seen another customer's data. The first hour is containment and counsel, not a cheerful "what still works." Or the buyer only wants a status-page template with your logo, and no one will ever open the product before sending it. A template is not the three sentences. Do not buy a build to avoid writing them.
Where the scope is a fixed repair rather than a standing team, an AI integration sprint can include the blank filled in before launch: the recipient, the sender, the interval, and the three sentences, with a login the agency actually holds. A white label software development partner who can only describe an incident by forwarding the subcontractor's paragraph is telling you, in advance, who will be believed on the night. The criteria are the login and the note. The paragraph can be excellent and still be someone else's.
On the evening the client writes, send the three sentences or send nothing that pretends to be them. Try the action. Name the stop. Say the cause is not known, and name the next update. Then go and find the cause, in a system you can open, and correct the note if sentence one or two was wrong. A correction is cheaper than a theory that lasts until morning. The client hired you to know what their product is doing. The first proof is that you can say so before you know why.
Find this useful? Tell Google to show you more of it.