lissy93/personal-security-checklist: a 300+ item digital security checklist you can self-host

What lissy93/personal-security-checklist actually is

This is not a scanner, an agent or a policy engine. It is a compiled list of more than 300 tips for protecting digital security and privacy, published as a repository, a website and an API. The stated audience is anyone who wants a structured starting point for securing their own digital life, and the README points readers at CHECKLIST.md as the canonical reading path.

The design decision that matters is where the content lives. Every checklist item sits in personal-security-checklist.yml. The website pulls that file in at build time, the API references it, and CHECKLIST.md is generated from it. That means a contributor who only wants to fix a recommendation edits one YAML file and nothing else. The README is explicit about this: if you only wish to make changes to the data, this is the only file you need to edit.

The project also carries a threat-model filter on the website, where you browse lists, filter by your threat model and tick items off once complete. That framing is the useful part. A generic security list is noise for most people; a list you can narrow by what you are actually defending against is closer to a plan.

The data flow: one YAML file, three outputs

The repository layout makes the pipeline readable. At the top level there is personal-security-checklist.yml, CHECKLIST.md, a lib/ directory, a web/ directory, a Makefile and a docker/ directory. The YAML is the source of truth. lib/generate.py rebuilds CHECKLIST.md from it, and lib/validate.py checks edits against lib/schema.json. The web/ directory holds a Qwik site written in TypeScript with some DaisyUI components, and that site consumes the same YAML at build time.

The API is a fourth consumer. The README gives the base as digital-defense.io/api and lists four endpoint shapes: /api/checklists, /api/checklists/[name-or-index], /api/checklists/[name]/[point-index] and /api/search/[searchterm]. All endpoints are documented in an OpenAPI spec, and the README says you can view and try them through Swagger docs, though the link in the README text is empty. That is a real gap: the endpoint paths are stated, the request and response shapes are not, so you have to hit the API to learn them.

One consequence of build-time consumption is that the API and the site are snapshots of the YAML at build or deploy time, not a live query against the file. If you fork the repository and edit the YAML, your fork's site reflects your edits; the public digital-defense.io instance does not.

Running the website locally and making a first checklist edit

The README gives a developing section for the website. It requires Node 20.19+ or 22.12+ and Git. Clone the repository, move into the web/ directory, install with yarn, and start the development server with yarn dev. The README also notes that opening the repository in Code Spaces gives you a preconfigured environment, which avoids the local Node setup entirely.

git clone [email protected]:Lissy93/personal-security-checklist.git
cd personal-security-checklist/web
yarn
yarn dev

The repository also ships a Makefile whose help target lists the common tasks. Note that make web.dev wraps the same yarn dev command, and make validate checks checklist edits against the schema before you open a pull request.

make help
make validate
make generate

If you would rather edit the data than the site, the workflow is: change personal-security-checklist.yml, run make generate to rebuild CHECKLIST.md, and run make validate to confirm the file still matches lib/schema.json. The Makefile installs its own Python virtual environment from lib/requirements.txt on first use, so you do not need to prepare one. For a static deployment, the README says to run yarn build.ssg and copy the resulting dist/ directory to any CDN, web server or static hosting provider.

Where the checklist stops being the right tool

A checklist tells you what to do. It does not tell you whether you did it, and the project does not claim otherwise. The website lets you tick items off, but the README does not describe accounts, cross-device sync or an export of your progress. If you need evidence for an auditor, a record of who completed which control and when, or a way to assign items to people, this repository gives you none of that. It is a reading and tracking surface for an individual, not a compliance platform.

The contribution model is another boundary. The README asks contributors to provide references backing up any information they are adding, amending or removing. That is the right rule for a security document, and it also means the checklist moves at the speed of reviewed pull requests. If your environment changed this morning, the checklist will not have caught up.

Finally, the repository carries a NOASSERTION licence label while the README and the LICENSE file both state MIT. GitHub uses NOASSERTION when it cannot match a licence file to a known template, and the LICENSE text in the README includes a small wording difference from the standard MIT text. Treat the label as a classification artifact rather than a second licence, but read LICENSE yourself before you rely on it.

How it compares with a general security framework

The natural comparison is a control framework such as the CIS Benchmarks or the NIST publications. Those are organised around systems and controls, written for organisations, and come with assessment procedures. This project is organised around a person, written in plain language, and comes with a YAML file you can parse. The difference in approach shows up in the output: a framework produces an audit result, this produces a to-do list you tick off.

Against a plain Markdown checklist, the difference is the data layer. Because the items live in personal-security-checklist.yml with a JSON schema in lib/schema.json, you can query them through the API, filter them on the site by threat model, or generate your own view. A Markdown list gives you text and nothing else. That is the trade: you take on a Node build and a Python validation step in exchange for structured content you can reuse.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-11-01. The repository has no published GitHub releases, which fits a content project: you track the master branch rather than a version tag. The practical upgrade path is git pull followed by make generate if you have local data edits, or yarn build.ssg if you deploy the site. There is no migration guide in the README and no documented rollback, so if you fork the data file, keep your changes in a branch you can rebase.

Licensing is MIT according to both the README and the LICENSE file, with copyright attributed to Alicia Sykes. MIT permits use, modification, sublicensing and sale provided the copyright notice and permission notice are included. The README text notes that the notice should be included in copies or substantial portions of the software, with a small typo in that sentence. None of this is legal advice; if you plan to redistribute the checklist inside a commercial product, have someone read the actual LICENSE file.

Editorial conclusion

Adopt it if you want a maintained, forkable checklist whose data lives in one YAML file and whose site you can build yourself; skip it if you need per-user accounts, sync or an audit trail, none of which the README describes. Before committing, run make validate against your edits, confirm the API base path at digital-defense.io/api still matches the endpoints in the README, and check that the NOASSERTION licence label on the repository is only a GitHub classification and not a conflict with the MIT text in LICENSE.

Frequently asked questions

Official sources

1. Issues
2. lissy93/personal-security-checklist on GitHub
3. Project website
4. README