Incident Response Plan

0. Who is on call

One person. Keln Holdings LLC is a very small operation, and the honest version of this section is that there is no 24-hour staffed rota and no second pager. Response is fast during waking hours and is not instant at four in the morning.

That is stated first rather than buried, because every clock below is a commitment made by one person and you should read them knowing that. Where a step needs a third party — a hosting provider, Stripe, the mail provider — their response time is outside our control and we will say so at the time rather than let a clock quietly run out.

1. What counts as an incident

Anything that has, or plausibly could have, one of these effects. If it is not on this list it is a bug, and bugs go through the ordinary queue.

• Confidentiality. Data belonging to one account became reachable by another, or by the public, or by us in a way we do not normally have.
• Integrity. Data was destroyed or altered other than by the person it belongs to — including by our own deployment.
• Availability. Keln is down, or a core function (sign-in, bookings, the pipeline) is unusable, for more than fifteen minutes.
• Account takeover. Any evidence that somebody signed in as somebody else, or could have.
• Third-party compromise. A provider we depend on — hosting, Stripe, the mail provider — discloses a breach that touches our data or our keys.

2. Severity

Set within one hour of the incident being recognised, and set deliberately high when it is unclear. A severity is easy to lower once the facts are in and almost never gets raised in practice, so the bias is upward on purpose.

• SEV-1 — customer data exposed or destroyed. Cross-account data access, a database leak, a confirmed account takeover, or irrecoverable data loss. Everything else stops.
• SEV-2 — total outage, or a credible vulnerability not yet exploited. Keln is down, or a report describes a real way in that we cannot yet rule out having been used.
• SEV-3 — degraded. A core function is broken or slow for some people; no evidence of data exposure.
• SEV-4 — contained. A security-relevant defect with no live exposure — a missing header, a rate limit that was too generous, a dependency advisory that does not apply to how we use it.

3. The clocks

These are the commitments. They start when the incident is recognised — the moment a human at Keln understands something is wrong — not when it began, because we cannot promise a clock on something nobody has noticed yet.

• Acknowledge a security report: within 24 hours, always, even if the answer is "we are still reading it".
• Set severity: within 1 hour of recognising an incident.
• Post to /status: within 1 hour for SEV-1 and SEV-2, and updated at least every 4 hours until resolved. A status page that only goes green is a marketing page.
• Notify affected accounts directly: within 72 hours of confirming that specific accounts were affected — by email, to the account address, naming what was exposed. Sooner where we can, and we will not wait for the full picture before telling you the part we are sure of.
• Publish a written post-mortem: within 14 days for any SEV-1 or SEV-2, on the changelog.

If a clock is going to be missed, the miss gets announced before the deadline rather than explained after it.

4. The first thirty minutes

In this order, and the order is the point. Preserving evidence before stopping the bleeding loses customer data; stopping the bleeding before preserving evidence loses the ability to say what happened, which is what the notification in step 3 depends on. The compromise is: capture cheaply, then contain.

• Write down the time and what was seen. A timestamped note, kept for the whole incident. Memory is unreliable and the post-mortem is due in 14 days.
• Snapshot before changing anything. Copy the current database file and the relevant logs somewhere they will not be overwritten by the fix or by the next scheduled backup. This takes seconds and is unrecoverable if skipped.
• Contain. The narrowest action that stops it: disable the affected route, revoke a key, ban an account, or take the service down. Taking Keln down is an acceptable response to a SEV-1 and does not need anyone's approval.
• Post to /status. Before diagnosis is complete. "We are investigating a problem with sign-in" is a true and useful sentence.

5. Runbook, by kind

The specific steps for the failures this system can actually have. Written per kind rather than as one generic procedure, because a leaked session secret and a bad deploy have almost nothing in common.

Session secret or database exposed

• Rotate SESSION_SECRET and restart. Every existing session becomes invalid, which signs everybody out — including whoever should not be signed in.
• Rotate the encryption key only after confirming the current one can still decrypt the backups, and re-encrypt rather than re-keying in place. A rotation that orphans the ciphertext turns a breach into permanent data loss.
• Force a password reset on affected accounts. Two-factor secrets and passkey credentials are separate: passkeys are unaffected by a database read, because the stored half is a public key and cannot be used to sign in.
• Rotate Stripe and mail-provider keys, and check each provider's own audit log for use we did not make.

Account takeover

• Destroy that account's sessions, and check whether a passkey or a second factor was added while the attacker held it — those survive a password change, which is exactly why they are the first thing to look at.
• Read back the account's own history: what was exported, what was emailed, what was deleted.
• Tell the owner what was done under their name, specifically. "Your account may have been accessed" is not an answer anybody can act on.

Data loss or corruption

• Stop writes first. A corrupted record that is still being written to is a corrupted backup in a few minutes' time.
• Restore from the most recent verified snapshot. Backups are verified on write and a snapshot that will not parse is refused rather than kept, so "the most recent" and "the most recent that works" are the same file.
• Name the window of lost data in the notification. An hour of lost work that somebody knows about can be redone; an hour they do not know about is discovered as a missing client six weeks later.

Outage

• Roll back before diagnosing. The previous version worked; understanding why this one does not is the second job.
• Check the dependencies before the code — hosting, database, mail, Stripe. Most outages of a small service are somebody else's outage.

6. What we tell you

A notification names what was exposed, when, for how long, whether we can tell if it was accessed, and what you should do. If we do not know something, it says we do not know rather than omitting it — an incomplete notification that reads as complete is a second incident.

We will not describe an incident as "a security event affecting a limited number of users" or any of the other phrases that exist to avoid saying what happened. If your prospects' email addresses were readable, the email will say that.

Where the law requires notification to a regulator — GDPR's 72-hour duty being the one most likely to apply — that runs in parallel with telling you, never instead of it.

7. Reporting something to us

Write to support with the words security report in the subject. Tell us what you found and how to reproduce it. We will confirm receipt within 24 hours, keep you updated, and we will not threaten you for looking.

Please do not run automated scans against production or access an account that is not yours. A proof of concept against your own account is enough, and it is what we would ask you for anyway.

8. After it is over

Every SEV-1 and SEV-2 gets a written post-mortem on the changelog within 14 days: what happened, the timeline, why it was possible, and what changed so that it is not possible again. Named systems, not "an internal process issue".

The rule for the fix is that it has to be a test or a structural change, not a resolution to be more careful. Anything that relies on remembering will be forgotten by the next incident, which is usually how there is a next incident.