Link each security statement to scoped evidence
Assign each security statement to a specific control owner, evidence reference, check date and next review. Distinguish a written policy from enforced behavior and an infrastructure assessment from application scope. Public wording should follow that evidence; an empty field signals a claim to withhold rather than reassurance to invent.
Worked example — illustrative data.
| Control topic | Evidence required | Control owner | Last checked | Next review | Permissible wording |
|---|---|---|---|---|---|
| Access roles | Current permission matrix and enforcement check | Product security owner role | Not assessed | 2026-12-04, example target | Describe only verified permissions |
| Retention and deletion | Approved data-flow/retention record | Data owner role | Not assessed | 2026-12-04, example target | No retention period asserted |
| Independent assessment | Actual report, product scope and validity | Assurance owner role | No report supplied | Before any assessment claim | No certification claim |
| Incident contact | Confirmed operational route | Incident-response owner role | Not tested | Before public contact claim | Use only a verified destination |
These are fictional register roles and review targets, not controls or assessments performed for a real SaaS product. Replace them with named responsible people, actual check dates and evidence before approving public statements.
Assign each public statement a control owner, source and review date. Separate a policy from technical enforcement: having a written procedure does not establish that the system implements it. Explain which product, environment or service the evidence covers. Keep sensitive implementation detail and confidential reports behind an appropriate reviewed request process. Use qualified security and legal review for material claims rather than treating the website draft as assurance.
A supplier audit does not certify the whole application
A hosting provider’s audit may cover its infrastructure while excluding the SaaS application’s configuration and practices. State the actual relationship and scope; do not copy the provider’s badge as if it certifies the whole product.
Publish a narrow verified statement or omit the claim until evidence is available. A truthful gap with a contact route is preferable to unsupported reassurance.
Continue with Guides for stores, software teams and local businesses, SaaS website design and development and Decide when a SaaS feature needs its own page.