Version 1.0 — September 2026. This is a publishable policy, written to be posted on the site rather than kept internally. It governs what gets written, how it gets sourced, what does not get published, and how errors are handled.
Part 1 — Purpose and scope
This site publishes practical, sourced cybersecurity information for individuals, businesses, security professionals, developers, students, executives, policymakers, investors, and organizations trying to understand and improve their security.
Everything here is educational. Nothing on this site is legal advice, financial advice, investment advice, or a substitute for professional counsel appropriate to your situation. Security decisions depend on facts we do not have about your organization.
This policy applies to every page, every newsletter, and every downloadable resource.
Part 2 — Sourcing standards
2.1 Source hierarchy
We prefer, in order:
- Primary government and standards sources — CISA, NIST, NVD, MITRE, OWASP, ENISA, FBI IC3, national CERTs and CSIRTs, regulators, and official advisories.
- Original technical research and vendor advisories, including incident-response reports and academic papers.
- Independent testing organizations — MITRE ATT&CK Evaluations, AV-Comparatives, AV-TEST.
- Credible original reporting from established security journalism.
- Vendor telemetry and surveys, cited with methodology and labeled as such.
We do not cite content-marketing blog posts as evidence for statistics. Where a figure originates in a vendor report, we cite the vendor report, not a secondary summary of it, and we say which it is.
2.2 Recency
For threats, products, breaches, regulations, pricing, and company status, we prioritize sources from the past 12 to 24 months. Older sources are used only for durable concepts, historical incidents, and standards that have not changed — and are labeled when the age is material.
2.3 Every claim carries its provenance
Each substantive factual claim on this site carries an inline link, a publication date, and — where it is a statistic — a label:
- Confirmed — official government or law-enforcement statements, court records, or victim disclosures.
- Vendor — statistics from commercial telemetry or surveys.
- Assessment — analytic judgment, including attribution and motive, by us or by a named source.
- Estimate — modeled, survey-based, or extrapolated figures.
We do not write "studies show." We name the study, its date, and its method.
2.4 Uncertainty and conflict
Where credible sources conflict, we say so and present both figures with their sources. Where a widely repeated statistic has a methodological weakness, we state the weakness at the point of use — not in a footnote. Where we do not know, we say we do not know.
Specific standing caveats we apply every time the relevant figures appear:
- FBI IC3 figures cover reported US losses only; underreporting is severe.
- Chainalysis ransom figures are a traceable floor, not a total.
- IBM Cost of a Data Breach figures use activity-based costing including soft costs, exclude mega-breaches, and are drawn from mostly mid-to-large enterprises. They are not predictive for small organizations, and per-record extrapolations are not valid.
- Vendor threat reports about their own platforms are unusually detailed and valuable, but independent verification of scope is generally not possible.
- Workforce "gap" figures are extrapolations from surveys of desired headcount, not funded requisitions.
2.5 Dating and review
Every page carries a last reviewed date. Frameworks, regulations, prices, and product details additionally carry a status as of line. Review cadence: monthly for threat and vulnerability content, quarterly for tools, pricing, frameworks, and regulations, twice yearly for careers, and immediately when an item is in active rulemaking or litigation.
Part 3 — Safety policy
This is the part of the policy that constrains what we publish, and it is not negotiable for traffic, for a partnership, or for a reader request.
3.1 What we do not publish
We do not publish material that provides meaningful uplift to someone attempting unauthorized intrusion. Specifically, we do not publish:
- Working exploit code, proof-of-concept exploits for unpatched issues, or weaponized payloads.
- Step-by-step procedures for gaining unauthorized access to systems, accounts, or networks.
- Malware source code, builders, droppers, or deployment instructions.
- Credential-theft techniques, tooling walkthroughs, or harvesting infrastructure.
- Detection-evasion, anti-forensics, or persistence techniques presented operationally.
- Instructions for defeating specific security products.
- Phishing kits, lure templates intended for real use, or social-engineering scripts for defrauding real targets.
- Guidance on laundering proceeds, acquiring illicit access, or operating on criminal marketplaces.
3.2 What we do publish, and how
We explain what a class of weakness is, why it matters, who it affects, how to detect it, and how to fix it. A reader should finish a page understanding broken object-level authorization, why it dominates API breaches, and how to test for and remediate it in their own application, under authorization — without holding anything they could paste at someone else's system.
The test we apply to every draft: does this page help a defender more than it helps an attacker? Where the answer is unclear, we cut the operational detail and keep the concept.
3.3 Offensive security and penetration testing
We cover penetration testing, red teaming, and ethical hacking exclusively as authorized, legal work and as education in self-contained labs.
Every page in this area states that testing systems you do not own, without written authorization from someone with authority over them, is a criminal offense in most jurisdictions regardless of intent.
We name assessment tools — Burp Suite, OWASP ZAP, Nmap, Metasploit, Kali Linux, Wireshark, Caldera, Atomic Red Team and others — only with their purpose and licensing, and only on pages that also carry the authorization requirement. We do not publish usage walkthroughs aimed at real-world targets.
We route every practice recommendation to legal environments: PortSwigger Web Security Academy, TryHackMe, Hack The Box, OverTheWire, CyberDefenders, VulnHub, picoCTF and CyLab Security Academy, or an in-scope bug-bounty program. Never toward live third-party systems.
3.4 Cybercrime coverage
We cover cybercrime as a threat landscape: prevention, detection, response, victim impact, and law enforcement. Attack patterns are described at a high level — enough to recognize and defend against them, not enough to reproduce them.
We do not glamorize criminal actors. We name groups where naming them is useful for defenders and where attribution is sourced, and we distinguish confirmed attribution from assessment every time.
3.5 Vulnerability coverage
We report on vulnerabilities that are publicly disclosed, and we prioritize those in CISA's KEV catalog or with confirmed exploitation. Our coverage answers: what is it, who is affected, is it being exploited, what should you do, and by when.
We do not publish exploit details beyond what is necessary for defenders to assess exposure and prioritize. Where a vendor has not yet shipped a fix, we follow coordinated disclosure norms and do not add detail beyond what the vendor or a coordinating body has released.
3.6 Consumer-safety content
The scam-awareness center and personal-security guides serve people who are actively being targeted, including older adults and people in distress. In that section we use plain language and large type, avoid jargon entirely, carry no advertising, and always include where to report and where to get help.
We do not describe fraud techniques in a way that would function as a manual. We describe what the victim experiences and what to do.
3.7 Editorial independence from commercial relationships
No sponsor, advertiser, or affiliate partner reviews content before publication. No commercial relationship influences a recommendation, a directory listing, or a comparison outcome. Directory inclusion is editorial and free. Comparison tables contain no affiliate links. We publish our current sponsor and affiliate relationships on a standing page. See the full commercial rules in section 5.
Part 4 — Product and vendor coverage
4.1 We do not call anything secure
No product, framework, certification, or configuration makes an organization secure. Every product page states that results depend on configuration, coverage, tuning, staffing, and monitoring, and names what the reader must operate for the tool to deliver anything.
4.2 Evidence hierarchy for product claims
Independent testing (MITRE ATT&CK Evaluations read in raw form, AV-Comparatives, AV-TEST) ranks above analyst positioning, which ranks above peer reviews, which ranks above vendor claims. We label vendor claims as vendor claims, including performance numbers vendors publish about themselves.
We note where independent evidence is missing. For example: several major vendors declined to participate in the 2025 MITRE ATT&CK Enterprise Evaluations. Absence of data is not evidence of weakness, and we say that — but we also say the data is absent.
4.3 Open-source alternatives
Every tool category names its credible open-source alternatives, with an honest statement of what they cost in engineering time. Open-source options are never omitted for lack of a commercial relationship.
4.4 Pricing
Prices carry a date and a source. We distinguish published list prices from negotiated ranges reported by third parties, and we state that enterprise security pricing is heavily negotiated. Prices are reviewed quarterly.
4.5 Vendor incidents
We report security incidents affecting security vendors with the same standards as any other incident. A vendor's own breach or outage is material information for buyers, and we do not omit it because the vendor is otherwise well regarded.
Part 5 — Commercial policy
- No paid placement in directories, comparisons, or rankings. Ever.
- Sponsorship is display-only and clearly labeled — never native, never adjacent to a recommendation.
- No pre-publication review by any commercial party.
- Affiliate links only where the recommendation would be identical without them; disclosed at the point of the link and in a standing disclosure; never in comparison tables.
- No affiliate relationship with any product we have declined to recommend, and no recommendation changes after a relationship begins.
- We publish the list of current sponsors and affiliate relationships.
- No sponsored content, vendor guest posts, or "thought leadership" placements.
- No advertising in the scam-awareness center or personal-security guides.
Part 6 — Corrections
We correct errors promptly and visibly.
Substantive corrections — any change to a fact, figure, recommendation, or conclusion — are noted at the top of the page with the date and what changed, and logged on a public corrections page.
Minor corrections — typography, broken links, formatting — are made silently.
Updates that reflect new information rather than an error are noted with an "updated" date and a short note on what changed.
Readers can report errors through a clearly linked contact route, and we respond. If a vendor disputes a characterization, we consider the evidence on its merits and correct if warranted; we do not remove accurate criticism on request.
Part 7 — Author and expertise transparency
Every page names its author and the date. Author pages state relevant background and any professional affiliations that could be perceived as a conflict.
Where content is AI-assisted in drafting, that is disclosed in the site's methodology page, along with the human review process applied. All factual claims are verified against the cited primary sources by a human before publication, regardless of how the draft was produced.
Part 8 — Handling requests we decline
We receive requests for material this policy prohibits. Our standing responses:
Requests for exploit code or attack procedures, however framed — for research, for a class, for a CTF, for a client — are declined. We point to lawful lab environments instead.
Requests to remove accurate negative coverage of a product or company are declined. We correct inaccuracy, not unfavorability.
Requests to add a product to a comparison in exchange for payment are declined, and the request itself is grounds for scrutinizing any existing coverage of that vendor.
Requests from readers in active distress — fraud victims, people being extorted — are answered by pointing to the right reporting channel and support resources, promptly and without judgment. We do not attempt to provide individual incident response or legal guidance.
Part 9 — Review of this policy
This policy is reviewed annually and whenever a novel situation arises that it does not cover. Material changes are versioned and logged on this page.
Policy version 1.0 — September 2026.