Editorial Policy

We publish security research, buyer guides, regulatory explainers and investigations. We also sell penetration testing, so we have an obvious interest in what we write. This page exists so you can check us rather than trust us. It describes rules we already follow, not aspirations, and the checks that run before anything reaches this site.

Who writes here

Every article carries the name of the person accountable for it, not a house byline. Most are written by Ashok Kamat or by Rathnakara GN and Ashok Kamat together, and delivery team members are credited when they did the work. Both founders are hands-on in every client engagement, so the person whose name is on a methodology post is the person who runs that methodology.

The one exception is our investigations work, which is published under the company name because it is a team output. Read more about the people behind it on our about page.

How we source a claim

We rank sources into three usable tiers, and we say which one a claim rests on.

• Primary sources. The thing itself: the statute or gazette notification, the regulator's own circular, the standards body's own document, the company's own pricing page, the original research report. This tier is required for anything we say a law or a standard requires, and for anything we say about a competitor's price.
• Authoritative secondary sources. Established outlets with editorial standards and a corrections policy, law firms of record publishing on their own domain, research houses that publish methodology alongside their numbers, and curated incident registries. Used as a second line, or as the first when the primary document is genuinely unreachable.
• Finding aids. Trade blogs, vendor marketing, listicles, aggregators and encyclopaedias. We use these to locate a primary source, then cite the primary source. We do not cite them as the basis for a fact.

For anything consequential we want two lines of evidence, and we apply an independence test to them. Four outlets running the same wire copy are one source. A law firm note and a trade article summarising the same gazette are one source, and the gazette is the source both should defer to. A statistic quoted by six blogs that all cite the same report is one source: the report.

When a claim cannot be sourced

It does not get published. In order of preference we replace it with a claim we can source that makes the same point, or soften it to an honest qualifier such as "typically" or "most", or attribute it explicitly to whoever said it, or cut it. What we do not do is publish it anyway, dress it up with a weak citation, or fall back on phrases like "industry sources say".

This rule costs us. A number that strengthens our argument and cannot be sourced is the most tempting thing on the page and the most dangerous, because we want it to be true. The reader is better served by a smaller true claim than a larger uncertain one, and that ordering holds even where it costs us a sale.

Statistics

We do not invent numbers. Every percentage, frequency or specific figure either cites the original report that produced it, or comes from a dataset of ours that we describe well enough for you to judge it. Where a figure exists but the population it covers is different from the point being made, we do not stretch it: a global all-sector average is not a SaaS figure, and we have made that mistake and corrected it in public.

Vague qualifiers are allowed without a citation, because they are honest about their own precision. Specific numbers without a source are not allowed, even when hedged. The test before publishing is simple: if a reader asked for the source on this number, could we produce it in under a minute.

Anything that decays is dated inline. Prices, statistics, regulatory status and any claim containing the words record, first, largest or only carry an "as of" date, because all of them go quietly wrong otherwise.

Standards and versions

We cite only released versions of the standards we work against, never a draft or an in-development version that sounds more current. At the time of writing that means OWASP Top 10:2025, OWASP WSTG v4.2, OWASP ASVS 5.0.0 and OWASP API Security Top 10 (2023). The full list we work against is on our methodology page.

The pinned version of each standard is recorded in this site's repository, and an automated weekly check compares those pins against the upstream projects. When a new stable release lands, or a draft appears that might tempt someone into citing it early, the check surfaces it for review rather than letting our pages drift.

Claims about our own work

This is the part most editorial policies leave out, and it is where a security vendor is most likely to be wrong. Statements on our commercial pages about what a client's report will contain are registered in a claims file in this site's repository. Each entry names the real engagement artefact it was verified against and the date somebody opened that artefact and looked.

A check in our deploy pipeline refuses to ship a promise about the deliverable when the registry is empty, and warns when any registered claim has not been re-verified in 180 days. The honest limit is worth stating: the check runs inside the repository and the reports are files outside it, so it cannot verify a claim against a report on its own. Verification is human. The gate makes skipping it hard rather than easy.

We built this after reading two real client reports against our own website and finding three gaps. One page promised that findings cite OWASP WSTG test identifiers. The real report contained none, because it maps findings to CWE instead. We replaced the sentence with what the report actually does, and the replacement is less impressive and more accurate. Two further claims of the same shape were caught by the new check within a day. What we deliver is described on our sample report page.

Corrections

We correct on the page rather than editing quietly. Where a published claim turns out to be wrong or has gone stale, the change is recorded in a dated Corrections section at the foot of that article, saying what was wrong and what replaced it. The convention started on 9 August 2026, and as of August 2026 it runs on 57 of our 84 blog posts, which are the ones that have needed it.

Every blog post carries a link to report an error, and it opens a message to errors@cybersecify.com with the page already filled in. That inbox is for corrections rather than sales, and a reader doing us a favour should not land in a queue built for buyers. You can write to it about anything on this site, not only blog posts.

If you are named in one of our investigations and believe a factual claim is wrong, or you hold context that would correct it, the same address reaches us. We publish verifiable corrections promptly. We do not remove published content on objection alone where no factual error is shown. The full position is in our terms of service.

Updates and freshness

When an article changes in a way that matters to a reader, it gets an updated date that is visible on the page and emitted in the page's structured data. That field means the page was improved. It is not a last-touched timestamp: typo fixes, byline changes and site-wide link sweeps do not bump it, because a field that moves for trivial reasons stops carrying information. A check in the deploy pipeline catches edited posts whose date was not bumped.

How we use AI

In engagement work, automated tooling and AI do first-pass analysis and surface mapping. Authentication, authorisation, business logic and chained-exploit analysis are tested by hand, and every finding is validated by a human before it reaches a report. We do not ship scanner output as a penetration test report, and we do not describe our process as a split where software finds things and a person tidies them up. The judgement, and the accountability for it, sits with the tester.

What we will not publish

• Invented client stories. No composite case studies presented as real engagements, and no findings attributed to clients who did not agree to it.
• Quality claims about named competitors. Assertions that another firm uses junior testers or ships templated reports are not evidenced and not fair. Where the point is worth making, we turn it into a question you can ask any vendor, including us.
• Recognition we have not received. Certifications, memberships, project statuses, partnerships, awards and press coverage are claimed only once the issuing body has confirmed them. Where something is pending, we say it is pending and name the body we are waiting on.
• Capability we have not confirmed. What we can and cannot do is answered by the founders, never inferred from what our own website happens to say or leave out.

Our commercial interest

We are a penetration testing and compliance services company. Our articles link to our services and our pricing is published openly so you can compare it. That interest does not buy anything on the editorial side: an unsourced claim comes out even when it helps us, and a correction gets made even when it makes us look less impressive. If you ever find those two things trading places on this site, that is exactly the sort of thing to send to the errors address.

Contact

Corrections and factual disputes: errors@cybersecify.com

Everything else, including press and research enquiries: our contact page