Website Incident Response Playbook: NIST-Based Plan for Small IT Teams

When a company website is defaced, starts serving malware, or quietly leaks its customer database, the difference between a bad day and an existential event is rarely technical skill - it is whether anyone wrote down, before the incident, who decides what, in which order, with which accesses. This guide gives IT managers at small and mid-sized organizations a complete, practical incident response plan for website and web-application incidents, built on the structure of NIST SP 800-61 and adapted to teams of one to five people rather than a 24/7 SOC.

Work through it once in calm conditions (roughly one working day), and you will have a printed playbook, a contact card, and tested backups - the three artifacts that consistently separate quick recoveries from week-long outages.

The incident lifecycle

Every credible framework uses some version of the same loop. Print this; it is the spine of the whole plan:

   +--------------+     +-----------------+     +--------------+
   | 1. PREPARE   | --> | 2. DETECT &     | --> | 3. CONTAIN   |
   |  plan, roles |     |    ANALYZE      |     |  stop spread |
   |  backups     |     |  triage, scope  |     |  preserve    |
   +--------------+     +-----------------+     |  evidence    |
          ^                                     +------+-------+
          |                                            |
   +------+-------+     +-----------------+     +------v-------+
   | 6. LEARN     | <-- | 5. RECOVER      | <-- | 4. ERADICATE |
   |  post-mortem |     |  restore,       |     |  remove      |
   |  fix causes  |     |  monitor,       |     |  cause,      |
   +--------------+     |  notify         |     |  patch       |
                        +-----------------+     +--------------+

Phase 1 - Preparation (do this now, not during the fire)

1.1 Define severity levels and who decides

Ambiguity about "how bad is this" wastes the first critical hour. Adopt three levels:

Level	Definition	Examples	Who is woken up
SEV-1	Confirmed compromise or data breach	defacement, malware served, database exfiltrated, ransomware	IT lead + CEO immediately
SEV-2	Strong indicators, no confirmed damage	credential stuffing spike, vulnerable component actively probed, admin login from unknown country	IT lead, business hours+
SEV-3	Suspicious but likely benign	single phishing report, scanner noise, one-off WAF block	logged, reviewed weekly

Name an Incident Commander (IC) - the person who coordinates, decides and communicates - and one deputy for vacations. In a small company the IC is usually the IT manager; the point is that it is one named person, not "the team".

1.2 Build the contact card

During an incident you will not have time to search for logins. Prepare a one-page card (printed and in a shared password manager) with:

Hosting provider: support phone/portal, account number, who holds admin access
Domain registrar and DNS provider: same
CMS/platform admin accounts and where their credentials live
CDN/WAF provider (Cloudflare etc.) access
Cyber-insurance policy number and 24h hotline, if insured
External IR/forensics firm you would call for a SEV-1 (pick one now; retainers are cheap compared to emergency onboarding)
Data protection authority contact (for Sweden: IMY; EU-wide list at the EDPB)
Internal: CEO, communications owner, legal counsel

1.3 Backups you have actually restored

A backup that has never been test-restored is a hope, not a control. Requirements:

3-2-1 rule: three copies, two media, one off-site - and the off-site copy must be offline or immutable (object-lock / snapshot), because modern ransomware deletes reachable backups first.
Backup scope: web root, database, server configuration (nginx/Apache, cron), TLS certificates and - often forgotten - the environment variables/secrets the app needs to boot.
Quarterly restore drill: restore to a scratch VM, boot the site, log in. Time it. That number is your realistic Recovery Time Objective, not the one in the policy document.

1.4 Detection you will actually notice

Small teams do not watch dashboards; alerts must come to them. Minimum set: uptime monitoring with alerting, file-integrity or defacement detection on the web root, admin-login notifications from the CMS, and external monitoring of your domain's security posture and certificate/DNS changes - FortifyNet's continuous monitoring covers the external half and emails you on change, which is precisely how defacements and expired certificates are usually caught late.

Phase 2 - Detection & analysis (the first hour)

When an alert or report arrives, the IC runs triage - in writing, in a dedicated channel (create #incident-YYYYMMDD), because the timeline you write now is the post-mortem and possibly the legal record later.

Triage questions, in order:

Is it real? Reproduce the symptom from an outside network (mobile hotspot) - CDN caches and split DNS often fool internal checks.
What is the scope? One page or entire site? Web server only, or database too? Are customer credentials or personal data plausibly involved? (This answer starts the GDPR clock - see Phase 5.)
Is it ongoing? Live traffic from the attacker, or the residue of a past event?
Assign severity from the 1.1 table and notify accordingly.

Evidence rule from the first minute: copy logs off the affected server immediately (access logs, error logs, auth logs, CMS audit trail). Attackers commonly delete logs; hosting providers rotate them within days. Do not power off a server you may need forensics from - isolate it instead (see below); powering off destroys memory-resident evidence.

Phase 3 - Containment

Containment stops the bleeding without destroying evidence. Choose the least destructive action that stops ongoing harm:

Site serving malware/defacement: put the site into maintenance mode at the CDN/load-balancer level, or geo-block/challenge all traffic. Users see a clean holding page; the compromised origin stays intact for analysis.
Compromised admin account: disable that account and rotate all admin credentials and API keys - assume the attacker harvested the credential store. Enforce MFA in the same change.
Server-level compromise: isolate at the network level (security group/firewall: block all inbound except your management IP). Take a disk snapshot before changing anything if your host supports it.
Database exfiltration: rotate database credentials, revoke external access, and preserve query logs.

Two containment mistakes to brief the team on in advance: (1) restoring from backup before understanding the entry point - you restore the vulnerability with the data and get re-compromised within hours; (2) communicating on potentially compromised infrastructure - if the mail server may be affected, coordinate on phones/Signal.

Phase 4 - Eradication

Find and remove the root cause, not just the symptom:

Establish the entry point from the evidence: unpatched CMS/plugin (the majority of small-business web incidents), stolen credentials, exposed admin panel, vulnerable upload form, or a hosting-level breach.
Rebuild rather than clean. For any server-level compromise, deploy a fresh server from a known-good image and migrate verified data into it. Cleaning a rooted box is unreliable; webshells hide in innocuous files and cron entries.
Patch the entry point everywhere it exists (staging too), update all components, and re-scan.
Rotate every secret the compromised system could read: DB passwords, API keys, OAuth secrets, TLS private keys if key material could have been read.

Phase 5 - Recovery and notification

Technical recovery

Restore service progressively: bring the rebuilt site up behind the CDN, run an external scan to confirm nothing malicious is served, watch error rates and logs at elevated attention for 72 hours, and keep the tightened firewall rules. If the site was flagged by Google Safe Browsing, request review via Search Console - delisting typically takes hours to a couple of days after cleanup.

Legal notification - the 72-hour rule

Under GDPR Article 33, a personal-data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, unless the breach is unlikely to risk individuals' rights. Article 34 additionally requires notifying the affected individuals when the risk is high (e.g. leaked passwords or payment data). Practical points:

The clock starts at awareness, not at full understanding. A partial report ("we have confirmed unauthorized access, scope under investigation") within 72 hours is compliant; silence is not.
Document the assessment even when you decide not to notify - the reasoning is itself required.
Organizations under NIS2 obligations have a faster track: early warning to the CSIRT within 24 hours, incident notification within 72 hours.

Communication

One voice: the IC or the designated communications owner. Internally, short factual updates at a fixed cadence (even "no change"). Externally, honesty beats spin - state what happened, what data was involved, what users should do (password reset), and what you have changed. Companies are rarely punished by customers for having an incident; they are punished for hiding it.

Phase 6 - Post-incident review

Within two weeks, run a blameless post-mortem (one hour, IC facilitates): timeline, root cause, what worked, what was slow, and 3–5 concrete actions with owners and dates - e.g. "enable auto-updates for plugins", "move backups to immutable storage", "add file-integrity monitoring". Feed the actions into the normal work backlog; an unassigned lesson is a lesson not learned.

Finally, schedule a tabletop exercise twice a year: pick a scenario (defacement discovered by a customer on Friday 17:30 is a classic), walk the team through this playbook verbally, and note every point where someone says "hmm, I'm not sure who…". Those pauses are the plan's bugs - fix them on paper before an attacker finds them in production.

Worked example - the Friday-evening defacement

Theory sticks better with a timeline. Here is how the playbook runs for the most common SMB scenario: a customer emails at 17:42 on a Friday saying your homepage "looks strange".

17:45 - Detect. The on-call IT manager (IC by default) opens the site from a phone on mobile data: the homepage shows an attacker's banner. Screenshot taken. #incident-20260828 channel created; SEV-1 declared (confirmed compromise); CEO texted per the severity table.
17:55 - Evidence. Before touching anything: access and error logs from the past 14 days copied off the server to local storage; CMS audit log exported; disk snapshot triggered at the hosting provider.
18:05 - Contain. Site switched to maintenance mode at the CDN. Customers now see a neutral "back shortly" page. All CMS admin passwords rotated from a known-clean laptop; MFA enforced; the one unfamiliar admin account found in the user list is disabled, not deleted (it is evidence).
18:40 - Analyze. The CMS audit log shows the rogue admin was created Tuesday 03:14 via a vulnerable gallery plugin (version three releases behind). Database tables for customers appear untouched per query logs - noted, with reasoning, in the channel for the GDPR assessment.
19:30 - Eradicate. Fresh server deployed from the host's stock image; latest clean backup (Monday) restored to it; CMS core and all plugins updated; the gallery plugin deleted outright; secrets rotated.
21:10 - Recover. DNS/CDN pointed at the new origin. External scan confirms clean content and headers. Maintenance mode lifted. Elevated log-watching agreed for the weekend, split between IC and deputy.
Monday - Notify & learn. GDPR assessment concluded: no personal data accessed, documented, no Article 33 report required. Post-mortem Wednesday produces three actions: auto-updates on, plugin inventory quarterly, file-integrity monitoring installed.

Total customer-visible downtime: about three hours, on a Friday night, with two people. That outcome is bought almost entirely in Phase 1 - the snapshot capability, the CDN maintenance switch, the tested backup and the severity table were all decided before 17:42.

Working with external parties

Three relationships determine how much help you get under pressure:

Hosting provider. Know in advance what they can do in an emergency: snapshots on demand? network isolation? log retention period? Their emergency response is often faster through the paid support tier - decide before the incident whether that tier is worth it (it usually is).
Forensics / IR firm. For any SEV-1 involving suspected data theft, ransomware or legal exposure, bring professionals in early - evidence handling mistakes in the first hours are irreversible. A named firm on a light retainer answers in hours; a cold call during a national ransomware wave may answer in weeks.
Cyber insurance. Read the policy now: most require notification within a fixed window and some require using the insurer's approved IR panel - engaging your own firm first can void coverage. Put both facts on the contact card.

If extortion enters the picture

If the incident comes with a ransom demand - for decryption, or for not publishing stolen data - slow down before anyone replies. Do not communicate with the attacker from personal or corporate accounts; involve legal counsel and, for significant demands, the police (in Sweden via polisen.se; many EU countries have national cybercrime reporting routes) before any contact. Paying is legal in most jurisdictions but funds the next attack, offers no guarantee, and may be sanctioned if the group is on a sanctions list - a check your legal counsel or insurer must make. Whatever is decided, decide it once, at management level, documented; extortion pressure is designed to force fast individual decisions, and the playbook's job is to prevent exactly that.

Measuring the capability

Two numbers, reviewed twice a year, tell you if the capability is improving:

MTTD (mean time to detect): time from compromise to awareness. The defacement example above had an MTTD of three days - the attacker got in Tuesday, you learned Friday. File-integrity monitoring would have cut it to minutes; that is the argument for the post-mortem action.
MTTR (mean time to recover): time from detection to restored service. Driven almost entirely by preparation quality: tested backups, pre-agreed containment switches, and a named decision-maker.

Tabletop exercises produce these numbers safely: time the walkthrough, note where the team stalls, and treat every "I'd have to look that up" as a finding.

Customer notification template

Have a draft ready so legal review is the only delay. Keep it factual, short and free of adjectives:

\`
Subject: Security incident affecting [service] - what happened and what we're doing

On [date] we detected unauthorized access to [system]. We took the
affected service offline within [X minutes/hours], removed the cause,
and restored service on [date/time].

What was affected: [specific data categories, or "no customer data,
based on our log analysis"].

What you should do: [reset your password / no action is required].

We have reported the incident to [authority] and engaged [external
experts] to verify our findings. We will update this page as the
investigation concludes: [status page URL].

Contact: security@yourcompany.com
`\

The one-page checklist

[ ] Severity table adopted; Incident Commander + deputy named
[ ] Contact card printed and stored in the password manager
[ ] 3-2-1 backups with an offline/immutable copy; restore drill done this quarter
[ ] Uptime, defacement and external posture monitoring alerting to phones
[ ] Evidence rule known: copy logs first, isolate - don't power off
[ ] Containment options pre-agreed with hosting/CDN provider
[ ] Rebuild-not-clean policy for server compromise
[ ] GDPR 72h / NIS2 24h notification duties mapped to your organization
[ ] Blameless post-mortem template ready; tabletop exercise scheduled

Sources

Originally published at fortifynet.com/blog/guide-website-incident-response. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.