Home › Free tools › Trust page
A trust page is the cheapest way to stop answering the same questionnaire. The paid ones host it for you, put their name on it and stop when you stop paying. This makes you a single HTML file: your answers, your domain, your page, working offline and loading nothing from anywhere. It starts from the answers you already keep in the questionnaire library, holds back the ones that are operational detail rather than reassurance, and refuses to publish a certification you have not told it you hold.
Runs in your browser. Nothing is sent anywhereOnly tick what you could produce today if asked. This is the section a buyer checks against reality, and the one where a stretch ends a deal later rather than winning it now.
The list buyers check first, and the one most trust pages leave out. It comes from your vendor register on this device.
Seventeen topics start unpublished because they are operational detail rather than reassurance. An answer still holding a bracketed instruction cannot be published at all, whatever you tick.
This is the file, rendered. It loads nothing from anywhere, so what you see here is exactly what a reader gets.
What you type on this page is held in this browser on this device so you can come back and regenerate. The answers themselves stay where they are, in the questionnaire library. Nothing is transmitted.
On your domain, by you. The tool hands you one HTML file. Put it at yourcompany.com/trust or /security, next to your privacy policy. It has no external references at all: no fonts, no scripts, no analytics, no images loaded from anywhere, so it renders from a memory stick with the network off. That also means nothing on it phones home to us, which is the point.
Use one if the extras are worth it to you: the paid products do document gating, NDA click-through, access logs and a record of who looked. What you trade is that the page lives on their domain with their branding, your posture is in their database, and the page goes away when the subscription does. A static file on your own domain does the main job, which is giving a buyer somewhere to look instead of a form to send you.
It cannot. Any answer still holding a bracketed instruction is refused rather than published, so the library's deliberate blanks cannot leak onto a public page. Certifications appear only if you tick them, and if you tick one that your own stored answer does not support, it says so before you generate. If you hold nothing, there is a wording for that which reads better than silence, because a buyer who cannot find the answer assumes the worse one.
Because a trust page is meant to let a buyer stop asking, not to be a map of where your locks are. Seventeen topics start unpublished: key handling, firewall and segmentation posture, monitoring thresholds, privileged access mechanics and so on. Those tell an attacker more than they tell a customer, and a careful buyer does not expect to see them in public. Every one of them can be published deliberately if you disagree.
It is the file at /.well-known/security.txt that tells a researcher who found a flaw where to report it, in the format set out in RFC 9116. It takes one line of your contact address and saves the researcher guessing, which is the difference between a quiet email and a public post. It is generated here because this tool already asks for the contact.
No. The page is built in this tab from what is already in this browser, and the file is produced by your browser rather than fetched from a server. Your library, your vendor register and anything you type here stay on this device.
Come back, change the answers, generate again, replace the file. The page carries the date you generated it, because a trust page with no date is worth very little and a buyer will ask. Tie it to something you already do quarterly, like the access review.