Information security policy

This policy says how LFW protects the systems it runs and the client systems it works in. It is written for a security reviewer, and it describes practice, not intent.

Version 1.0, October 6, 2026. Part of the published practices on the trust page, with the access control policy, the incident response plan and the acceptable use policy.

1. Scope and owner

The policy covers LFW.com, the Client Portal at my.lfw.com, the staff administration site, the server they run on, LFW’s working equipment, and LFW’s access to client systems.

LFW is one person. Leland Fiegel, its founder, owns this policy and is its only staff member as of September 27, 2026. Where a control depends on a second person, this policy says so rather than implying one exists.

2. Where LFW’s systems run

LFW’s own applications run on one server at Hetzner in Ashburn, Virginia, behind Cloudflare. The host firewall accepts web traffic only from Cloudflare’s address ranges, so the server cannot be reached directly from the internet on the web ports.

SSH is by key only, with password sign-in and empty passwords refused. The application, its database and its search index listen on the loopback address. fail2ban bans addresses after repeated failed connections.

Visitors reach the site over TLS 1.3 with a one-year HSTS policy; TLS 1.0 and 1.1 are refused. Traffic between Cloudflare and the server is also encrypted.

The staff administration site and the Client Portal are separate origins (admin.lfw.com and my.lfw.com). A script injected into a public page cannot act as a signed-in staff member or client, because neither session cookie reaches the public site.

3. The application

Every page sends a content security policy that authorizes scripts and styles by hash, with no inline script allowance, together with the standard headers: no MIME sniffing, a strict referrer policy, and a permissions policy that denies camera, microphone and location.

Every write to the application is checked for the origin it came from, and public endpoints are rate limited per address. Uploads are typed by inspecting their bytes, never by the sender’s claim; SVG is refused; a request may carry three files of up to eight megabytes each.

Private links (reports, quotes, invitations) use random tokens of at least 72 bits. Secrets live in one file on the server readable by root and the service account only. The repository holds no secrets.

4. Building and releasing

Every release is built in a disposable container that holds no keys, no private files and no server access. Dependency install scripts are off; only two native packages are rebuilt, by name.

The build fails on a lint error, a wall-of-text or casing error, a duplicated component rule, a known vulnerability of high severity in either production dependency tree, or a failing test.

A dependency version published fewer than seven days earlier is refused. Poisoned releases are normally withdrawn inside that window, so the wait is the control.

A release is activated as a whole, after the new release answers its public and protected route checks, and the previous release is kept for rollback.

5. Backups

The server’s data directory, databases, secrets and configuration are backed up with restic: encrypted and deduplicated, once a day and at every release. The backup directory is readable by root only.

Each database is copied with SQLite’s own online backup before it is stored, so a snapshot is consistent. The repository is checked weekly.

Retention: the ten most recent snapshots, 30 daily, 26 weekly, 24 monthly and 10 yearly. An encrypted copy of the repository is also kept off the hosting account, in a private Cloudflare R2 bucket.

A client site’s backups are the host’s. LFW checks periodically that they run and restores from them when needed, as the retainer schedule says.

6. Logging and monitoring

The web server records each request with its source address. The Client Portal keeps an append-only history of changes to requests and documents, records every staff view of a client account, and records each sign-in token as it is used so none can be replayed.

LFW Monitor checks LFW.com every day the way it checks client sites: accessibility, broken links, speed, TLS, email authentication records, the content security policy and the other security headers. Uptime is checked every minute, and the footer of every page reports it.

On a client site, LFW Activity Logs records who changed what inside WordPress and when, so an incident can be pieced together with the host’s access logs.

7. Client sites

LFW takes on a site only with three things in place: a managed host in the client’s name, a firewall inside WordPress (Wordfence Premium) licensed for the site, and Cloudflare in front of the host with its web application firewall and DDoS mitigation on.

WordPress core, themes and plugins are updated monthly from version control, with automated checks after each release. A security release is applied ahead of the monthly cycle. Between updates, the firewalls block known attacks, including attacks on a flaw made public before its fix exists.

8. Review of LFW’s own systems

LFW reviewed LFW.com, its endpoints, the server, DNS and email authentication, and the repository on September 16, 2026, by inspection and unauthenticated probing of its own property. No vulnerability was found that an unauthenticated visitor could use.

The one moderate finding, file permissions that let a second service account on the host read LFW’s databases, was fixed the same day and is now held by a test. The remaining findings were hardening items, accepted as they stand, and are recorded privately.

No independent penetration test of LFW’s systems has been commissioned yet. Where a client’s contract calls for one of the client’s site, LFW arranges it and reports the result.

9. Reporting a problem

Security reports go to security@lfw.com, named in security.txt. The vulnerability disclosure policy, with its scope, rules and safe-harbor commitment, is published at lfw.com/security.

A person replies within two business days. Business hours are 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.

10. What this policy does not claim

LFW holds no SOC 2 or ISO 27001 report and conforms to no named framework. It does not claim disk encryption for the live database on its server, FIPS-validated cryptography, or a network intrusion detection system.

This policy changes in the open: the version and date above move when it does, and the previous text stays in the repository’s history.