Incident response plan

This plan says what LFW does when a security incident is suspected or confirmed, on its own systems or on a client’s site. It is short because LFW is small: one person acts, and this is the order they act in.

Version 1.0, October 6, 2026. Part of the published practices on the trust page. Response steps for a client site follow the retainer schedule.

1. What counts as an incident

Unauthorized access to a system LFW runs or works in; a compromise of a client site; loss or exposure of client or visitor data; a credential of LFW’s that may have leaked; or a failure of LFW’s own release process that takes a site down.

A vulnerability report with no sign of use is handled under the vulnerability disclosure policy, not this plan, unless it shows that data was reached.

2. Who acts, and when

Leland Fiegel, LFW’s founder, owns every incident. There is no on-call rotation and no after-hours coverage: LFW acts in business hours, Monday to Friday, 9 a.m. to 5 p.m. Eastern (6 a.m. to 2 p.m. Pacific), excluding federal holidays. We do not offer after-⁠hours or on-⁠call coverage.

Outside those hours a client’s host monitors and supports the servers around the clock under its own terms, and a client can report a compromise in the Client Portal at any hour. LFW begins restoring a compromised client site from the host’s backup by the next business day.

3. Notice

If LFW confirms a security incident that touches a client’s data or a client’s site, it tells that client within 24 hours of confirming it, in writing, by email to the contacts on file, with what is known, what is not yet known, and what LFW is doing.

Where a client’s contract or the law sets a shorter window or a named contact, that applies. LFW complies with applicable breach notification laws and supports the client’s own notice to the people affected.

A security researcher who reports a problem under the disclosure policy hears back within two business days, then learns the plan and when the fix is live.

4. Steps for LFW’s own systems

Contain. Revoke the affected sessions or tokens; rotate any secret that may have been exposed; if needed, block the traffic at Cloudflare or stop the service.

Preserve. Keep the web server logs and the application’s records for the period. Take a backup snapshot before changing anything, so the state at discovery survives.

Restore. Roll back to the previous release, which is kept on the server, or restore the data from the most recent good snapshot. Backups run daily and at every release, with an off-site copy.

Fix and verify. Ship the fix through the normal gated release, then confirm it on the live site with LFW Monitor’s checks and by hand.

5. Steps for a client site

Contain. Tighten the firewall rules at Cloudflare and in Wordfence, reset the site’s administrator sessions and credentials with the client, and take the site to maintenance mode if it is actively harming visitors.

Restore. Restore from the host’s most recent clean backup, beginning by the next business day, as the retainer includes. The host’s plan sets how far back a backup reaches.

Investigate. Read the activity log and the host’s access logs to find how and when the site was reached. Deeper forensics and cleanup beyond the restore are a project, quoted in writing before the work begins, as the schedule says.

Close the hole. Update or remove the component that was used, confirm the firewall rule that covers it, and recheck the site with LFW Monitor.

6. The written record

Every incident gets a private written record: what happened, when it was found, what was done and when, what data was involved, and what changed afterward so it does not repeat. The client receives that record for an incident on its site or involving its data.

Public changelog entries describe the fix, never the incident’s details. Where an incident changes a practice on the trust page, the policy’s version and date move.

7. Testing this plan

The release process is tested on every deploy: a new release answers its route checks before traffic moves, and the previous release stays available. Backups are verified as they are taken, and the backup repository is checked weekly.

LFW has not yet run a scheduled restore drill against a copy of its production data, and says so here rather than claiming an annual test.