When a security incident touches a customer, you are suddenly writing two things at once: the internal record your auditor will read later, and the update your customer needs right now. Most teams do the first in a ticket and the second in a scramble of one-off emails. Neither ages well.

The internal record is the easy part to get right, because frameworks tell you exactly what it needs (ISO 27001 Annex A 5.24 through 5.28, and the incident-response evidence a SOC 2 auditor expects). The customer update is where teams improvise, and improvising during an incident is how you end up either saying too little (a customer hears about it from someone else) or too much (details leak that you cannot walk back).

Why a public status page is the wrong tool here

Public status pages are great for "is the API up." They are the wrong instrument for a security incident. A public page announces to every visitor, including press, competitors, and attackers, that something is wrong, before you have the facts straight. And it cannot say anything specific to the one customer who was actually affected, because it is speaking to everyone.

The other common approach, a thread of manual emails, has the opposite problem. It is private, but it does not stay current. The customer replies asking for an update and you are back to hand-writing status at the worst possible time.

What good incident communication actually looks like

The pattern that works is narrow and boring in the best way:

  • Private, and scoped to one incident. The people you notify see this incident and nothing else. There is no universal URL that reveals your incident history.
  • Only what you chose to publish. Your internal notes, root cause analysis, and lessons learned stay inside your company. The customer sees a plain-language summary and the updates you deliberately publish.
  • Live, so it answers itself. A status page that updates in place means the customer stops emailing you for status, because the status is always there.
  • Yours, not a generic third party. The page should carry your name and brand, so it reads as an official communication from you.
  • Provably reaching the right person. A link that anyone can open if it gets forwarded is not private. Access should require proving you are the person it was sent to.

How Keel does it

Keel's incident module keeps your internal record (report, triage by severity, contain, root cause, lessons learned, and a one-click corrective action), and adds a way to share status with the specific customers affected.

You turn sharing on for a single incident, write a plain-language impact statement, and add each affected contact. Each one gets their own private link to a status page for that incident only. On it they see a live timeline, a phase stepper (investigating, contained, resolved), the severity, when it was last updated, and, if you set one, when to expect the next update. They can acknowledge receipt so you know they saw it, subscribe to be notified of new updates, reach the contact you designated, and save a clean, branded PDF for their own records. The page carries your logo and brand color, reused from your Trust Center.

Crucially, the page is not open to anyone who holds the link. The first time a recipient opens it, Keel emails a six-digit code to the exact address the link was issued to and asks them to enter it before anything is shown. If the link gets forwarded, the forwarded copy is useless, because the code only ever goes to the original recipient. Codes are single-use and expire quickly, and once someone verifies, their browser is remembered for a week so they are not asked again every visit.

On your side, you stay in control the whole way. You decide what each update says and whether it is published to customers or kept internal. You can set a link to expire, resend a recipient their existing link, revoke any link instantly, and see a read-receipt roll-up of who has viewed and acknowledged.

The compliance side comes for free

Because the same incident record drives both the internal workflow and the customer-facing page, you are not maintaining two systems. The lifecycle you run for Annex A 5.24 through 5.28 is the same one your customers watch progress, and every incident stays a durable, timestamped record you can hand an auditor. When an incident warrants a corrective action, you promote it into the CAPA register in one click, pre-filled and linked back.

Incidents are stressful enough. The communication around them should not be the part you improvise.

Keel runs your whole ISO 27001 and SOC 2 program, incidents included, and you can stand it up in an afternoon with no sales call. Start free or see how incident management works.