Editorial Policy

How Topscan researches, reviews, updates, and corrects blog content

Last updated: 4 Nov 2026

Topscan.me publishes cybersecurity articles on vulnerability management, exposure management, and network and infrastructure security: scanning, prioritization, remediation, security metrics, and the tools behind them. We write them for technical teams who need to understand a security concept or make a decision, and we try to keep every claim current and traceable to its source.

The rules below apply to everything we publish on the Topscan blog.

1. Editorial Responsibility

The Topscan team writes most articles on our blog, and they are published under the Topscan Team byline. Before publication, Aleksandr Melnichuk, Chief Product Officer, reviews them for technical accuracy, clarity, relevance, and usefulness. Aleksandr also writes some articles himself, and those carry his name. Articles by other authors or contributors carry their names.

We are responsible for everything in the final published version of every article, from its factual claims and calculations to its source links, examples, and product descriptions. We try to keep analysis, interpretation, and recommendations visibly separate from verifiable facts.

Topscan is a commercial cybersecurity platform, not an independent news organization. Because of that, we disclose our product and business interests in the articles they affect.

2. How We Choose Topics

We cover questions that can materially affect CTOs, DevOps teams, engineering leaders, security practitioners, and organizations responsible for their own systems, from attack surface management to CVE and CVSS interpretation, patching, and tool selection. We prefer topics where a clear explanation helps the reader make a concrete decision, such as what to prioritize, what a metric actually measures, or what to verify before adopting a tool.

Headlines and summaries match what the article says, and we avoid unsupported promises of complete security, guaranteed compliance, perfect detection, or risk elimination.

3. Research and Source Standards

The more weight a claim carries, the stronger its source needs to be. For technical standards, vulnerability records, exploitation status, vendor capabilities, and regulatory or framework requirements, we prefer primary sources when they exist.

Our preferred sources include:

NIST publications and the National Vulnerability Database (NVD) for standards, vulnerability records, and technical references;
the CVE Program (CVE.org) for CVE records, and MITRE CWE and ATT&CK for weakness types and attacker techniques;
CISA advisories, the Known Exploited Vulnerabilities (KEV) Catalog, and CISA's SSVC guidance for documented exploitation and remediation decisions;
FIRST documentation for CVSS and EPSS;
other national cybersecurity agencies and CERTs, such as the UK NCSC, ENISA, and CERT/CC;
OWASP and CIS for application security testing and secure configuration guidance;
IETF RFCs and IANA registries for network protocols, DNS, TLS, and port assignments;
the bodies that publish compliance standards, such as the PCI Security Standards Council, ISO, and AICPA, and the official texts of laws and regulations;
official vendor and cloud provider advisories, product documentation, release notes, security bulletins, and open-source project repositories when describing a specific product, tool, or vulnerability.

For context, or when primary evidence is unavailable, we also use independent research with a published methodology (peer-reviewed papers and annual breach and threat reports such as the Verizon Data Breach Investigations Report), established security publications, and incident reports. We credit terms and frameworks introduced by industry analysts to the analyst firm, as with Gartner's Continuous Threat Exposure Management (CTEM). If we cannot verify a vendor's marketing claim independently, we attribute it to the vendor.

If a source changes over time, we note the version, publication or access date, product edition, or other context the claim depends on, when we can.

4. CVE, CVSS, KEV, and Exploitation Claims

Cybersecurity databases answer different questions. A CVE identifier names a publicly disclosed vulnerability; a CVSS score describes technical severity under a defined scoring system; a KEV entry indicates known exploitation according to CISA. None of them shows whether a particular organization is affected or what its full business risk is. If we combine CVSS, EPSS, KEV, asset exposure, business importance, and compensating controls into a single risk score, we explain the method.

For an article about a specific vulnerability, we aim to confirm:

the CVE identifier and the affected product or version;
the published score and its scoring version;
the vendor's guidance;
any credible exploitation evidence relevant to the article.

We do not describe a vulnerability as actively exploited just because public exploit code exists. When exploitation status is relevant, we look for evidence from sources such as CISA, the affected vendor, government advisories, or well-supported threat research, and we name the source.

5. Real Incidents, Attack Paths, and Security Examples

When we use a real incident or a historical vulnerability to explain a concept, we separate what was publicly documented from what we infer, as far as the sources allow. For attack paths, breaches, exploits, and remediation failures, we prefer original advisories, incident reports, court or government records, vendor statements, or well-sourced technical analysis. If the exact cause of an incident is disputed or unknown, we say so and label assumptions as assumptions.

We mark hypothetical examples as hypothetical and do not use them as evidence that a specific organization, product, or deployment is vulnerable.

6. Testing and Scanning Workflows

The same scanning method or tool workflow can behave differently depending on the product version, configuration, permissions, network path, cloud environment, or target system. If an article relies on our own hands-on testing or a controlled demonstration, we try to describe the conditions well enough for readers to understand the result. An article based on public documentation does not suggest that we benchmarked or verified performance ourselves.

Screenshots and interface examples may be cropped, annotated, or have sensitive data masked, and may show an earlier version of a product. They illustrate the point of the article and are not a guarantee of a product's current interface or behavior.

7. Metrics, Formulas, and Benchmarks

A security metric can mislead when its numerator, denominator, time window, population, or status definitions are unclear. For numbers in our articles:

With formulas and worked examples, we try to define the calculation and the reporting assumptions a reader needs to reproduce it.
An illustrative calculation is not an industry benchmark unless the article names a reliable benchmark source and its methodology. A sample percentage, MTTR calculation, SLA result, or severity distribution in an example is not a performance target for every team.
When we compare data across periods or organizations, we point out material differences in scope, asset inventory, scan coverage, severity rules, verification status, or reporting method that we know about.

8. Product Comparisons and Reviews

In product comparisons, we try to choose criteria that fit the use case the article describes, such as asset coverage, prioritization evidence, remediation workflow, deployment requirements, or operating effort. If a comparison is based on public vendor documentation and other verifiable sources, with no hands-on benchmarking, the article says so.

The order of products is not a ranking unless the article states and explains a ranking method. A product that fits one environment can be wrong for another, so readers should confirm coverage, licensing, deployment requirements, and current capabilities with the vendor before buying.

9. Topscan Product References and Commercial Transparency

MEETTY - FZCO, the company that develops the Topscan platform, publishes the Topscan blog and holds editorial responsibility for it. Some articles therefore discuss Topscan features and use cases or include Topscan in comparisons with other products. We aim to be impartial on general security topics, but we cannot be fully objective about our own product.

Any comparison, recommendation, or example that includes Topscan says that Topscan is our product, and claims about Topscan need the same evidence as claims about any other product.

We describe only Topscan features that are available today and never present planned, experimental, or unreleased functionality as a current capability. The blog does not sell links or publish paid guest posts. If a sponsorship, affiliate compensation, or another commercial relationship affects an article, we disclose it.

10. Responsible Security Content and Authorization

We write for legitimate security work: education, risk reduction, and testing of systems that the reader owns or is explicitly authorized to assess. We discuss vulnerabilities, attack paths, exposed services, and testing techniques so that readers can understand and reduce risk.

We do not encourage unauthorized access, destructive testing, denial-of-service activity, credential theft, data destruction, or scanning of third-party assets without permission. Readers are responsible for confirming that their testing is authorized and permitted by applicable law, contracts, hosting providers, cloud platforms, and internal policy.

Where a technique could create operational risk, we favor controlled, non-destructive validation and make relevant limitations clear.

11. Standards and Compliance

For standards and assurance frameworks such as NIST guidance, CIS Controls, OWASP resources, ISO 27001, SOC 2, or PCI DSS, we try to describe what the cited source requires or recommends, and we name the relevant version when it makes a difference.

A security tool, scan result, report, or article cannot by itself guarantee compliance or certification. Compliance depends on scope, evidence, implementation, organizational controls, and the judgment of the relevant auditor, assessor, customer, regulator, or other authority.

Content on the Topscan blog is general technical information, not legal advice, audit assurance, certification, or a substitute for professional advice tailored to a specific organization or jurisdiction.

12. AI and Editorial Tools

AI tools help our team research topics and prepare first drafts of articles. The team then proofreads and edits each draft and adds its own experience and opinions. Before publication, Aleksandr Melnichuk reviews the articles written by the team (see section 1). People make every publishing decision and are responsible for what we publish.

We check material factual claims, vulnerability identifiers, technical standards, quotations, calculations, vendor features, and source links against appropriate sources before an article goes live. We never treat AI output as a source: when an AI tool suggests a reference, we open and read it before citing it.

If a quotation, figure, or test result comes only from an AI tool, we leave it out, and we never use an AI summary to attribute words or views to a named person or organization. When preparing blog content, we give AI tools only public information: customer data and other non-public information do not go into them.

We do not intentionally publish fabricated citations, invented test results, or synthetic quotations as factual material.

13. Updates and Corrections

Vulnerability records, exploitation status, standards, products, and vendor documentation all change after an article is published, so we may review and update articles over time. If we find a factual error, misleading statement, broken source, incorrect calculation, outdated product claim, or material omission, we aim to correct it promptly.

When a page displays an updated date, it indicates that the article has been revised since its original publication. A minor typo fix may not require a new date, while a substantive technical revision should be reflected appropriately.

14. External Links and Third-Party Claims

We link to external pages so readers can check important claims against original documentation and other useful technical resources. A link does not mean that Topscan endorses every statement, product, service, policy, or business practice on the destination website.

We may replace or remove links that become broken, misleading, or outdated. When a vendor changes a product name, feature, package, or documentation page, we may update the article to keep its original meaning and current accuracy.

15. What Our Articles Can and Cannot Do

Content on the Topscan blog is educational and informational. It can explain security concepts, standards, methods, trade-offs, and evidence, but it cannot establish that a specific environment is secure, identify every vulnerability, guarantee successful remediation, or prove compliance.

A clean scan or the absence of a known CVE does not guarantee that a system is secure. Automated tools have coverage limits, findings can require validation, and security decisions depend on the reader's environment, asset importance, exposure, architecture, and operational constraints.

Readers remain responsible for testing authorization, remediation decisions, production changes, incident response, compliance decisions, and the security of their own systems.

16. Questions about This Policy

If you have a question about an article on the Topscan blog, a source, a correction, or this editorial policy, email info@topscan.me or use the contact page. Please include the article URL and the specific claim or passage you believe should be reviewed. We aim to reply within a few business days.

Vendors whose products we mention can report factual errors about those products. We check the report against the vendor's documentation and correct verified errors, but we do not change our assessments or the order of products on request.