Incident plan — [CLIENT] / [PROJECT]

One page. Filled in at kickoff, walked through once so I am not reading it for the first time during an incident.

Client contact: [NAME], [ROLE] — [PHONE] / [EMAIL] Backup contact: [NAME] — [PHONE] Agreed notification window: within [X] hours of me confirming an incident Is personal data in scope? yes / no

An incident is anything that suggests client data was exposed, altered or lost, or that an account or credential of mine is out of my control. If I am unsure whether something counts, I treat it as one and stand it down later.

1. Detect

Triggers: an alert fires, a job fails in a way I cannot explain, a credential appears somewhere it should not be, a client says something looks wrong, a provider notifies me of a breach, a device is lost or stolen.

First action: write down the time and what I saw, before touching anything. The timeline is the thing I will wish I had.

2. Contain

In this order:

1. Revoke or rotate the credential involved. Speed beats tidiness here.
2. Stop the affected job and take the output offline if it may be wrong or exposed.
3. Preserve evidence — copy logs before anything rotates them away. Do not clean up before I have looked.
4. Only then start working out what happened.

Do not delete, do not overwrite, do not "fix and see."

3. Notify the client

Within [X] hours of confirming an incident, by phone and then in writing. Even if I do not yet know the scope. What I say:

• What happened and when I found it.
• What data is potentially involved, and what I have ruled out so far.
• What I have already done to contain it.
• What I need from them.
• When they will hear from me next, and I hold that time.

The client is the controller. If personal data is involved, the decision about notifying a supervisory authority or data subjects is theirs, not mine — my job is to give them the facts fast enough that they can make it.

4. GDPR 72-hour assessment

If personal data may be involved, assess immediately — the controller's clock is 72 hours from their awareness, so my delay eats their time.

Record:

• ☐What categories of personal data, and roughly how many people
• ☐What actually happened — exposed, altered, lost, or contained
• ☐Likely consequences for those people
• ☐What has been done and what is planned
• ☐Time I became aware; time I told the client

Then hand it to the client in writing and say plainly that I believe this may be a notifiable personal data breach and the 72-hour assessment sits with them. I do not decide it for them and I do not tell them it is not notifiable.

5. Post-mortem

Within a week of closing it out, one page, no blame:

• Timeline: what happened, when I knew, when I acted.
• Root cause — the real one, not the last thing that broke.
• What contained it, and what made it worse.
• What changes in baseline-runbook.md or the project checklist as a result.
• What I would have needed to catch it sooner.

Shared with the client. A post-mortem I keep to myself is not a control.

Incident log