Editorial Policy
This document sets out the standards every article on HackNews is held to: how we source and verify information, who is accountable for what we publish, how we handle conflicts of interest, when we use AI tools, and how we correct mistakes. It applies to staff editors, contributors and guest authors without exception.
1. Our editorial mission
HackNews exists to give readers an accurate, useful and non-alarmist picture of what is happening in cybersecurity. We measure our work against one test: after reading an article, does the reader understand what happened, whether it affects them, and what to do about it?
We favour clarity over drama. We do not inflate incident severity to attract clicks, and we do not describe every vulnerability as critical. Where the honest answer is "this affects a narrow set of users and most readers can ignore it," we say that.
2. Independence
HackNews is editorially independent. No advertiser, sponsor, vendor, investor or commercial partner has any influence over what we cover, how we cover it, or whether a story runs.
- Editorial decisions are made solely by the editorial team. Commercial staff have no veto and no advance access to unpublished stories.
- We do not accept payment to publish, amend, delay, or delete an article. Offers to do so are declined and, where relevant, disclosed to readers.
- We do not offer "guaranteed positive coverage," paid reviews, or link insertion in editorial articles.
- Any sponsored or partner content is labelled Sponsored at the top of the page, is visually distinct from editorial, and is excluded from our news feeds and news sitemap.
- Affiliate links, if used, are disclosed in the article and never influence which product is recommended.
Our funding sources and ownership structure are disclosed in full on the Ownership & Funding page.
3. Sourcing standards
3.1 What counts as a source
We prioritise primary sources in this order:
- Official disclosures: vendor advisories, CERT-In and CISA bulletins, regulatory filings, court documents, breach notification letters.
- First-party technical evidence we can inspect ourselves: samples, IOCs, packet captures, published proof-of-concept research.
- Named human sources with direct knowledge, on the record.
- Established research from named security firms and academic teams, with methodology stated.
Aggregator posts, unattributed social media threads, and AI-generated summaries are never used as a sole source. If a competing outlet broke a story, we credit and link to them rather than laundering their reporting as our own.
3.2 Two-source rule
Any material factual claim that is not documented in a primary source requires corroboration from a second independent source before publication. If we cannot corroborate it, we either hold the story or publish it clearly framed as an unverified claim.
3.3 Attacker claims
Ransomware groups and data brokers lie routinely, to inflate their reputation and pressure victims. When we report on a leak-site listing or an extortion claim, we:
- state explicitly that the figure or claim originates from the attacker;
- contact the named victim organisation for comment before publishing where practical;
- never link to, mirror, or describe how to reach the leak site or the data;
- update the article when the victim confirms, denies, or corrects the claim.
3.4 Anonymous sources
We grant anonymity only when a source faces a genuine risk of legal action, employment loss, or physical harm, and when the information cannot be obtained on the record. When we do, we tell readers why anonymity was granted and what the source's position is relative to the events described. Anonymity is not a courtesy extended to PR representatives or to people who simply prefer not to be named.
4. Verification before publication
Before a story goes live, the assigned editor confirms:
- every factual claim traces to a source we can name in the piece or in our records;
- technical details, CVE identifiers, affected version ranges and patch status have been checked against the vendor advisory;
- named organisations and individuals have been given a reasonable opportunity to respond, and their response, or non-response, is reflected;
- numbers, dates and timelines are internally consistent;
- the headline is supported by the body of the article and does not overstate it.
5. Bylines and accountability
Every article carries the name of the human editor responsible for it. That byline links to an author profile with that person's background and complete archive.
- We do not use fake bylines, invented personas, or stock author photos.
- We do not publish under a generic house byline except for routine service notices, which are marked as such.
- Contributed and guest articles are labelled, and the contributor's affiliation is disclosed where it is relevant to the subject.
6. Use of artificial intelligence
We use AI tools the way we use a spell-checker or a search engine: as assistance, never as an author.
| Permitted | Not permitted |
|---|---|
| Grammar, spelling and readability checks. Transcribing recorded interviews. Summarising long public documents for an editor to then read in full. Translating source material, verified afterwards by a human. | Generating article text for publication. Producing quotes, statistics or sources. Writing headlines or summaries that no editor has verified. Creating images presented as photographs of real events. |
No article is published without a named human editor reading it end to end and taking responsibility for every claim in it. Where an AI tool has materially shaped a piece beyond the assistance described above, we disclose that in the article.
7. Responsible disclosure and harm limitation
Security journalism can cause harm if handled carelessly. Our rules:
- We do not publish working exploit code, weaponised proof-of-concepts, or malware samples.
- We do not publish technical detail that provides meaningful new offensive capability while a patch is unavailable and users remain exposed.
- We do not link to, host, or describe how to obtain leaked data, and we do not republish personal information found in breach dumps.
- We do not name individual victims of cybercrime, fraud or harassment without their consent, and we never name minors.
- Where a researcher's identity would expose them to legal or physical risk, we withhold it at their request.
- When we learn of an unpatched vulnerability directly, we notify the vendor and hold publication for a reasonable remediation window, unless the flaw is already being exploited and readers need to defend themselves now.
8. Conflicts of interest
- Contributors must disclose to the editor any employment, consulting relationship, equity holding, bug-bounty payment or personal relationship connected to a subject they are covering.
- Where a conflict exists and the coverage still has clear value, the relationship is disclosed inside the article. Where it cannot be managed, the story is reassigned.
- Hacklido runs cybersecurity training and community programmes. Whenever HackNews covers Hacklido, Techonquer, or any affiliated venture, that relationship is stated plainly in the article.
- Editors do not trade securities in companies whose security incidents they are actively covering.
- Gifts, paid travel, and hospitality from vendors are declined. Conference passes accepted for reporting purposes are disclosed in the resulting coverage.
9. Fairness and right of reply
Any organisation or individual facing significant criticism or allegation in our reporting is contacted for comment before publication and given a reasonable deadline to respond. If they respond after publication, we add their statement to the article and note that it was added.
We do not run "no comment" as a substitute for having asked. If we could not reach someone, we say what we did to try.
10. Corrections and updates
Errors are corrected promptly and visibly. Substantive corrections carry a dated note explaining what was wrong and what changed. We do not silently rewrite published articles. The full process, including how to request a correction, is on the Corrections Policy page.
11. Diversity and inclusion
Security is a global field, and our sourcing should reflect that. We actively seek researchers and commentators from outside the small circle of frequently quoted Western vendors, including voices from India and the wider Global South. We describe people accurately and avoid framing that reduces anyone to their nationality, gender, caste, religion or background. Our team is small; where our coverage falls short of this standard, we welcome readers telling us so.
12. Plagiarism and attribution
Plagiarism results in immediate removal of the article and termination of the contributor relationship. We quote sparingly, always with attribution, and we link to the original reporting rather than summarising it in a way that replaces it. Images are used only where we hold rights or a valid licence, and are credited.
13. Reader privacy
How we handle reader data, analytics and cookies is documented on the Privacy Policy page.
14. Review of this policy
This policy is reviewed at least annually and updated whenever our practices change. The review date at the top of this page reflects the most recent revision.
If you believe an article breaches any standard on this page, write to [email protected] or call +91 63670 98233. Complaints are reviewed by an editor who was not involved in the original story wherever staffing allows.