It is late, something is broken or exposed, and the strong instinct is to work out how it happened. That instinct is the expensive one. Understanding takes hours and the damage continues while you read. This page is an order of operations you can follow while your judgement is poor.

The idea

Work outward from the damage. Stop it spreading, cut off whatever access was gained, then find out how far it reached, then repair, and only then explain. Each step is cheap and reversible on its own, which is what makes the order safe to follow before you understand the incident. Write down what you do as you do it, with timestamps, because you will need that record for the last step and you will not remember it accurately tomorrow.

code
  1  contain    take the surface down or roll the deploy back
        |
  2  rotate     new key, deploy, revoke the old one
        |
  3  scope      logs: what was accessed, by whom, between when and when
        |
  4  restore    from backup, into a copy first
        |
  5  tell       affected users, and the regulator if required
        |
  6  write up   one page, next week, on what would have caught it

How it works

Containment is whatever makes the damage stop now. For a bad deploy, that is rolling back to the previous version rather than fixing forward, because a rollback has a known outcome and a fix does not. For an exposed endpoint, it can be taking that route or the whole site offline for twenty minutes. Downtime is recoverable. A dataset being copied is not.

Rotation follows immediately, and covers more than the one key you noticed. If a .env file was committed, every value in it is compromised, including the database password and the webhook secret. Rotate the whole file.

Scope is the step people skip, and it is the one that decides what you owe other people. Your provider's logs are the evidence: Supabase and Vercel both keep request logs, and your payment provider keeps an audit trail of what the key did. You want three answers. Which records could have been reached, from when to when, and whether anything was actually read or changed rather than merely exposed.

Restoring belongs after scope, not before, because restoring a backup over a live database can overwrite good rows written since the incident began. Restore into a separate database first, look at it, then move the rows you need.

Telling people comes last and is not optional when personal data was involved. Under Article 33, a breach of personal data must be reported to your supervisory authority without undue delay and where feasible within 72 hours of becoming aware of it, and Article 34 requires telling the affected people directly when the risk to them is high. The message says what happened, what data was involved, when, what you have done, and what they should do.

What to do

  1. Contain before you diagnose. Roll back, or take the surface offline, and note the time.
  2. Rotate every credential that shared a file or a machine with the exposed one.
  3. Pull the logs for the window and save them somewhere outside the affected system, before retention deletes them.
  4. Keep a plain running note as you go: what you saw, what you changed, when. It becomes the notice and, later, the write-up.

Where it breaks

This order assumes two things many small projects do not have. It assumes a restorable backup, which means one you have actually restored at least once, and it assumes logs with enough retention to cover a leak you found a week late. Without them, step three ends in "I cannot tell", and the honest position is to treat the whole affected dataset as exposed. That is worth knowing now rather than at 1am. The other failure is the fix that reintroduces the problem, deployed at speed by someone tired. Once the damage has stopped, stop. The write-up can wait for daylight.