Process documented 2026-08-09; public log not yet live
Corrections Policy
If Security Checklist publishes a material factual error, especially one that could affect a purchase, we want to fix it. This page describes the intake, verification, and update process. A dated public corrections archive is not live yet; until then, treat this as the process commitment rather than a log of past corrections.
Direct answer
Send the page URL, the incorrect statement, and a better primary source if you have one via /contact/. Material errors that affect scores, prices, availability, testing status, or who-should-not-buy guidance are prioritized over cosmetic typos.
Confirmed errors update the page and the claim ledger. When a change would reasonably affect a purchase decision, we note it on the page update label or a short corrections note rather than silent rewrite theater.
- Primary sources preferred in correction requests
- Affiliate payout disputes are not editorial score corrections
- Security vulnerabilities use /security/, not this channel
Purpose
Corrections protect readers from stale prices, misstated features, or unsupported “tested” claims. They also keep claim ledgers honest across data-privacy, password-manager, and antivirus coverage.
- Invite sourced challenges to published claims
- Prefer transparent updates for material changes
- Keep this route noindex until the public log ships
Policy
Material errors affecting scores, prices, availability, or testing status should be corrected promptly once verified. Cosmetic typos may be fixed without a public note.
We do not invent “updated daily” badges. Update labels should reflect real verification work. Overall scores remain N/Pub until signed test records exist, even when starting prices are ledger-verified.
- No fabricated coupons or scarcity as “corrections”
- Vendor marketing is not treated as independent evidence
- Enterprise and consumer claim standards stay separate where documented
Process
1) Intake via /contact/ with URL, quote, and source.
2) Triage for materiality and safety (security issues escalate to /security/).
3) Verify against primary sources and existing claim ledgers.
4) Update page copy, fixtures, and ledger fields as needed.
5) Adjust update labels; add a public log entry when that archive exists.
- Triage → verify → update ledger → publish fix
- Retire unsupported “tested” language if records are missing
- Escalate unresolved disputes through Contact
Accountability
A public corrections log may be added later under this URL or a dated archive page. It is not claimed as live today.
Editorial policy, methodology, and affiliate disclosure define what we will and will not claim while research continues.
- Editorial policy: /editorial-policy/
- Methodology: /methodology/
- Affiliate disclosure: /affiliate-disclosure/
- Contact: /contact/
Contact or escalation
Correction requests: /contact/. Do not send passwords, MFA codes, or payment credentials. Security researchers: security@securitycheckli.st and /security/.
- How we test: /how-we-test/
- About: /about/
- Privacy (counsel stub, noindex): /privacy/
Limitations
- Public corrections archive is not yet available.
- Use /contact/ or intel@securitycheckli.st for correction requests.
- Response times are not guaranteed.
Expert guides & insights
Related pages
Trust, tools, and category hubs that connect to this policy.
Want launch updates?
The email newsletter is not running yet. Use Contact if you want a human reply when it opens. No fake signup form.