Prepare Your Team for a Security Incident With a Simple Runbook

TL;DR — Before an incident happens, put four things in place: a written contact list, a shared incident runbook, verified backups, and a tested alert/communication path. The single biggest win is assigning exact roles and storing the runbook somewhere your team can still reach if your main systems are down. Reading time: ~5 min

Goal

When you finish, your team will have a usable incident response starter kit: a shared runbook, named responders, emergency contact details, backup and logging checks, and a short practice drill that proves everyone knows where to go and what to do.

Prerequisites

• Your company password manager login with permission to create or edit shared vault items
• Access to your document system where the team can edit a shared file (for example Google Docs, Microsoft 365, or Notion)
• Access to your chat tool admin area or team settings (for example Slack or Microsoft Teams)
• Access to your hosting or cloud dashboard where your app, database, and backups are managed
• Access to your DNS or domain provider dashboard if your website or email might need emergency changes
• A list of current team members with job titles, mobile numbers, and backup contacts
• The names of your key vendors: hosting provider, email provider, DNS provider, payment provider, and identity provider (login system)
• A video meeting tool your team already uses for emergency calls

Steps

Step 1: Create one shared incident runbook document

In your document system, create a document named exactly:

Security Incident Runbook

Paste this template into the document:

1. Incident owner
Primary:
Backup:

2. Technical lead
Primary:
Backup:

3. Communications lead
Primary:
Backup:

4. Decision maker
Primary:
Backup:

5. Emergency contacts
Hosting provider:
DNS provider:
Email provider:
Identity provider:
Payment provider:
Legal/compliance:
Cyber insurance:

6. Critical systems
Production app URL:
Admin URL:
Cloud dashboard:
Database location:
Backups location:
Logs location:
Status page:

7. First 15 minutes checklist
- Start incident call
- Freeze risky changes
- Confirm what is affected
- Preserve logs and screenshots
- Rotate exposed passwords, API keys, and tokens
- Check backups
- Post internal update

8. Evidence log
Time:
Who:
Action taken:
Result:

9. Recovery checklist
- Remove attacker access
- Patch root cause
- Restore from backup if needed
- Verify service health
- Notify affected customers if required
- Write post-incident review

What you should see when this succeeds: a shared document exists and opens for your incident team.

Step 2: Fill in named roles and exact contacts

In that same document, replace every blank field with literal names, phone numbers, and URLs. Use this table format in the document:

Then add your vendor contacts in this exact format:

```text
Hosting provider: support@examplehost.com / account ID 123456
DNS provider: dns@exampledns.com / zone example.com
Email provider: support@examplemail.com / tenant example-co
Identity provider: support@exampleidp.com / tenant example-co
Payment provider: support@examplepay.com / merchant ID 987654
Legal/compliance: legal@example.com / +1 555 0104
Cyber insurance: claims@exampleinsurance.com / policy CYB-2026-001

What you should see when this succeeds: every role has a named person and backup, and every vendor line has a real contact.

Step 3: Store emergency access in your password manager

In your password manager, create a shared folder or vault named exactly:

Incident Response

Add entries for these items:

Production hosting dashboard
DNS provider
Domain registrar
Email admin
Identity provider admin
Database admin
Backup system
Status page
Password manager emergency access instructions

If your password manager supports notes, add this note to the vault:

Use this vault only during a security incident or approved drill. Record every access in the Evidence log in the Security Incident Runbook.

What you should see when this succeeds: the incident team can open one shared vault and see all emergency systems listed.

Step 4: Create a dedicated incident communication channel

In your chat tool, create a private channel named exactly:

#incident-response

Pin the runbook link and post this message:

This channel is only for active security incidents and drills. Primary meeting link: https://YOUR-MEETING-LINK. Runbook: https://YOUR-RUNBOOK-LINK. Incident owner starts updates every 15 minutes until resolved.

Also create a calendar event named exactly:

Quarterly security incident drill

Set it to repeat every 3 months for 30 minutes.

What you should see when this succeeds: the private channel exists, the runbook link is pinned, and the recurring drill appears on the calendar.

Step 5: Verify backups and write down the restore path

In your hosting or cloud provider dashboard, open the backup area for your app and database. The menu path varies by provider; use your provider's dashboard (for example: Hosting Dashboard → Databases → Backups, or Cloud Console → Storage → Backups).

Record these exact values in the runbook:

Last successful app backup: YYYY-MM-DD HH:MM TZ
Last successful database backup: YYYY-MM-DD HH:MM TZ
Restore location: dashboard path or URL
Retention period: X days
Restore owner: Full Name

If your provider offers a restore test in a staging environment (a non-production copy), run one now and record the result.

⚠️ Do not restore into production during preparation. A production restore can overwrite live data and cause downtime.

What you should see when this succeeds: the runbook shows the latest successful backups and the exact place to start a restore.

Step 6: Verify logs are available and retained

In your hosting, application, and identity provider dashboards, open the logs or audit log area. Common paths are similar to:

Hosting Dashboard → Logs
Application Dashboard → Audit Log
 Identity Provider Admin → Audit / Sign-in Logs

Record these exact values in the runbook:

Application logs location: URL or dashboard path
Server or hosting logs location: URL or dashboard path
Identity/login audit logs location: URL or dashboard path
Log retention: X days
Export method: CSV / JSON / provider export button

What you should see when this succeeds: you can open recent logs for each critical system and know how long they are kept.

Step 7: Freeze emergency changes into a short checklist

Add this exact checklist to the top of the runbook under "First 15 minutes checklist":

- Pause deployments
- Pause marketing site edits
- Do not delete logs
- Do not reboot systems unless the technical lead approves it
- Rotate exposed credentials
- Take screenshots of alerts and error messages
- Write every action in the Evidence log

What you should see when this succeeds: the first page of the runbook tells the team what to stop and what to record.

Step 8: Run a 15-minute practice drill

Start a meeting using your normal video tool and post this message in #incident-response:

DRILL: Assume an employee password was stolen and suspicious logins were detected. This is a practice drill. Do not change production systems unless the step says "simulation only".

During the drill, complete these actions in order:

1. Incident owner opens the runbook
2. Technical lead opens logs and identifies where login events appear
3. Communications lead posts a 2-sentence internal update in #incident-response
4. Backup owner states the latest successful backup time
5. Decision maker confirms who can approve customer communication

Use this flow during the drill:

[Alert] ---- 1. posted in chat ----> [Incident owner]
[Incident owner] ---- 2. starts call ----> [Team]
[Team] ---- 3. checks logs/backups ----> [Evidence log]
[Decision maker] ---- 4. approves actions ----> [Team]
[Communications lead] ---- 5. posts update ----> [Staff]

What you should see when this succeeds: the team can find the runbook, join the call, identify logs and backups, and post an update within 15 minutes.

Verify it works

Use this checklist and confirm every item is true:

- The document named "Security Incident Runbook" exists and is shared with the incident team
- The runbook contains named primary and backup owners for 4 roles
- The password manager contains a shared vault named "Incident Response"
- The private channel #incident-response exists with a pinned runbook link
- The runbook lists the last successful app and database backup times
- The runbook lists where to find application, hosting, and identity logs
- A quarterly calendar event named "Quarterly security incident drill" exists
- A 15-minute drill was completed and the Evidence log contains at least one entry

You should expect: every item above is present without asking a single person "where is that stored?".

Common pitfalls

The runbook is stored only inside the affected system

Mistake: keeping the runbook only in the same app, wiki, or email system that may be down during an incident.

Symptom: the team cannot open instructions when they need them.

Fix: store the runbook in a separate shared document system and pin the link in your chat channel.

Only one person has admin access

Mistake: the main technical contact is the only person who can reach hosting, DNS, or email admin.

Symptom: response stalls when that person is asleep, traveling, or unavailable.

Fix: add a backup owner for every critical system in the shared password vault.

Backups exist, but nobody knows how to restore

Mistake: recording that backups are "enabled" without writing the restore path or testing it.

Symptom: during an incident, the team wastes time searching the dashboard.

Fix: write the exact dashboard path or URL for restore and test a non-production restore.

Logs are too short or not enabled

Mistake: assuming logs will be there later without checking retention (how long logs are kept).

Symptom: suspicious activity happened days ago, but the evidence is already gone.

Fix: open each log area now, record retention days, and increase retention in your provider settings if the option exists.

The drill turns into a real production change

Mistake: someone rotates live credentials or restores data during a practice session.

Symptom: avoidable outage, broken integrations, or locked-out users.

Fix: start the drill with the exact message "This is a practice drill" and use simulation-only actions unless a step is explicitly approved.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.