Methodology
How FISRO checks information before it is published, and how we tell readers what we know and what we do not.
The question behind every piece
Each FISRO publication should answer, in this order: what happened; where and when; which facts are confirmed; who it matters to; what is still unknown; what can be done; and which sources it relies on. If we cannot answer the first three with evidence, we do not publish.
Sources
We record every source we rely on in a source register: its title, publisher, address, publication date, the date we accessed it, and whether it is primary or secondary.
Primary sources are the people and records closest to the facts: the maintainers of affected software, vendors’ security advisories, official vulnerability records, court documents, regulators, and our own observations.
Secondary sources are reporting by others. We cite them when they add something, such as a timeline, a reproduction or a statement, and say who established each fact. We do not rewrite another outlet’s story and present it as our own.
Where possible we keep an archived copy of web sources, because advisories and posts change.
Claims
Significant statements in a piece carry a status:
| Status | Meaning |
|---|---|
| Confirmed | Supported by at least one primary source we have checked, or by our own evidence. |
| Reported | Stated by a credible secondary source; we have not confirmed it independently. |
| Disputed | Credible sources disagree. We describe each position. |
| Unknown | Not yet established. We say so rather than guess. |
Where a publication needs a separate claims register, it appears with the supporting sources. Other pieces attribute factual statements in the text and source list, with uncertainty explained at the relevant point.
Technical evidence
For vulnerabilities, we take affected and fixed versions from the maintainer or vendor wherever possible and cite the specific advisory for each row of an affected-software table, with the date we last checked it. Where only secondary sources are available, the table says so. We do not publish working exploit code or step-by-step instructions that would mainly help attackers.
For original research involving infrastructure, malware or datasets, the methodology section of the piece describes what data we collected, how, over what period, what we excluded, and the limits of the conclusions.
Review before publication
Every piece is drafted, then reviewed by an editor who checks it against the source register before it can be published. Investigations, and any piece that names individuals, makes allegations or touches on sensitive subjects, require approval from at least two people other than the author, one of whom checks the evidence specifically.
AI-assisted tools may support source research, drafting and illustration preparation. Material use is disclosed in the article methodology. Technical examples are identified as proposed checks or exercises unless the article reports an actual reproduction. The editorial workflow requires human release approval; an automated source-access check is not treated as human fact-checking.
Dates and updates
Times on FISRO are given in UTC. Case studies distinguish the event or disclosure date from the editorial archive date. Source and archive-date corrections retain their provenance in the editorial record. An “updated” date identifies a substantive change, described in the article’s update log. Typographical corrections do not make an old story look new.