Keep off a public security page anything that helps an attacker or misleads a buyer: internal hostnames, exact versions of exposed software, unredacted reports, customer names, and claims you cannot back with evidence. Publish posture, contacts, and policy openly. Put detail behind a request step that you control.
The short list
Most teams publish too little or too much. The table below sorts common items by where they usually belong. It is a starting point, not a rule set, and your own risk review has the final say.
| Item | Public page | Gated | Why |
|---|---|---|---|
| Security contact and reporting policy | Yes | No | Researchers need to find it fast |
| High-level control descriptions | Yes | No | Buyers want to see posture |
| Subprocessor list and data locations | Yes | No | Common first question |
| Full audit or test reports | No | Yes | Often carries detail you do not want loose |
| Internal hostnames, IP ranges, tool names per system | No | Rarely | Helps reconnaissance |
| Customer names and logos | Only with written consent | No | Contract and trust issue |
| Full SBOM files | Depends | Often | See the decision guide linked below |
| Unfinished controls described as live | No | No | Misleading |
Detail that helps attackers
A buyer needs to know that you patch, monitor, and test. An attacker wants to know which product version runs on which host. Describe the practice, not the inventory. "We scan dependencies on every build and track fixes to closure" tells a reviewer what they need. A list of internal tools per environment does not add trust, and it narrows the search for anyone probing you.
The same logic applies to shared SBOMs. CISA's 2026 minimum elements guidance says access controls may limit sharing of SBOM data with unauthorized parties, but should not stop sharing between authorized parties or block them from loading the data into trusted security tools. So gating is fine. Blocking real customers is not.
Claims you cannot evidence
The quickest way to lose a reviewer is a claim that falls apart under one follow-up question. Words like "fully secure," "unhackable," or "compliant with everything" invite exactly that question. Keep each sentence tied to something you can show: a policy, a log, a report, a dated plan.
If a control is in progress, say so and give the state. If an audit report is not finished, do not imply it is. A SOC 2 report is an attestation issued by an independent CPA firm, so a page that says "SOC 2 certified" is using the wrong word before it even gets to the facts. The AICPA describes SOC as a suite of services CPAs may provide as assurance reports.
A simple test before you publish
Ask three questions about each line:
- Could someone use this to plan an attack on us?
- Could someone read this as a promise we have not kept?
- Can we show evidence today if a customer asks?
If the answer to the first is yes, or the answer to the third is no, rewrite or remove the line. Then give the page one owner and a review date so it does not drift. A related post covers who should own the trust page.
Where Safeguard fits
Teams use Safeguard's SBOM and dependency scanning, plus compliance and evidence automation, to keep the evidence behind security page claims current. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is it safe to list the security tools we use?
Naming categories of practice is usually fine. Listing every tool by system gives outsiders detail with little trust value. Share tool detail in a gated answer when a buyer asks.
Should the page include a penetration test report?
Usually no. Publish that you test and how often, and offer a summary or the report through a request step.
Sources
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA
- System and Organization Controls: SOC Suite of Services, AICPA and CIMA
Last reviewed: 19 October 2026.
