Company
Editorial Policy
How content on this site is researched, reviewed, fact-checked, corrected and re-checked — and what we refuse to publish.
Why this page exists
Security content on the open web is unusually unreliable. Much of it is produced at volume for search traffic by writers with no working knowledge of the systems described, and the resulting advice is frequently outdated, subtly wrong, or right in a way that is useless in practice.
We publish this policy so our output can be held to a stated standard rather than an implied one — and so you can tell when we have failed to meet it.
Who writes what
Articles touching cryptography, our architecture, or specific technical claims are written or technically reviewed by someone who has worked on the relevant code. Research, comparison and general privacy articles are written by Inkrypt Editorial and technically reviewed before publication.
Where we describe something outside our direct experience — another product's internals, a standard we have read but not implemented — the text says so explicitly and cites the primary source. We do not present secondhand knowledge as operational experience.
Sourcing standards
Every factual claim about an algorithm, standard, or third-party product must trace to a primary source. In descending order of preference:
- Standards documents — RFCs, NIST publications, W3C specifications.
- Recognised security guidance — OWASP cheat sheets, CIS benchmarks.
- Vendor primary documentation — a company's own technical docs, for claims about that company's product.
- Peer-reviewed cryptographic research, for claims about attacks or algorithm properties.
- Our own measurements, clearly labelled as such, including how they were taken.
Claims that cannot be sourced are cut rather than hedged. "Some experts believe" is not a source, and we do not use it. Secondary reporting is not used as a source for a technical claim, though it may be cited for context.
On statistics
Technical review before publication
Draft
The author writes with sources attached to each factual claim.Technical review
A second person with relevant working knowledge checks every technical assertion. Anything they cannot verify is removed or rewritten to a claim that can be supported.Consistency check
Claims about our own product are checked against the shipping code and against the security architecture page, so documentation and implementation cannot silently diverge.Clarity edit
The draft is edited so a non-specialist can act on it without a specialist finding anything they would have to correct. Where those goals conflict, we add explanation rather than removing accuracy.Publish with a date
Every article carries a publication date and, where it has been revised, a last-updated date.
What we will not publish
- Fabricated testimonials, user counts or reviews. If we ever display social proof, it will be real and attributable.
- Invented statistics, or figures whose original source we cannot locate.
- Fear-driven framing that overstates a risk to make our product look necessary.
- Claims about competitors we have not verified against their own documentation.
- Security guarantees we cannot support. This is why the threat model lists what we fail at, not only what we defend against.
- Undisclosed paid placement. We do not accept payment for coverage or links. If that ever changes, it will be disclosed on the page in question.
Corrections
We will get things wrong. When we do:
- Material errors — anything that could lead a reader to a worse security decision — are corrected as soon as they are confirmed, with a dated correction note on the article.
- Minor errors such as typos or broken links are fixed without a note.
- Corrections are never silent deletions. If a claim was wrong, the page says it was wrong rather than quietly removing it.
- Reporting an error: email work.securetext@gmail.com or use the contact form. Point to the specific claim; we will respond either way.
Scheduled review
Security guidance decays. Recommended iteration counts rise, algorithms fall out of favour, and products change their architecture. Content that was accurate in 2024 can be actively misleading by 2027.
| Content type | Reviewed | Trigger for immediate review |
|---|---|---|
| Security architecture and threat model | Every 6 months minimum | Any change to our cryptographic implementation |
| Feature and product pages | Every 6 months | Any change to the feature described |
| Technical articles | Annually | New standards guidance, or a relevant published attack |
| Comparison articles | Annually | A compared product changing its architecture or pricing |
| Glossary | Annually | New terminology entering common use |
Reviewed pages carry a visible "last reviewed" date. A review means someone re-checked the claims — not that the file was touched.
AI use
We do not publish machine-generated articles. Language models are used the way a spell-checker or a search engine is used — for drafting assistance, rephrasing and finding sources — but every published claim is verified by a person against a primary source, and every article has a human author accountable for it.
We state this plainly because the alternative is now common and largely undisclosed, and because it is the difference between content that has been checked and content that merely sounds checked.
Independence
Inkrypt is a product, and these pages exist partly to explain that product. We think the honest way to handle that is to be explicit about the conflict rather than pretend it does not exist.
In practice that means: we name situations where a different tool is the better answer, including on our own feature pages; we document our limitations on the same pages as our strengths; and we do not publish comparisons engineered to make competitors look worse than they are. If you find us failing any of those, tell us — that is a correction we want to receive.
Frequently asked questions
Who reviews technical content before it is published?
How do I report an error?
Do you accept payment for reviews or links?
Is any of this content AI-generated?
How often is content updated?
Found something we got wrong?
Point us at the specific claim and we will check it. Material errors get a dated correction on the article itself.
Open the notepad