What to put on a security page
When a serious customer asks how you protect their data, they are working through a mental checklist. This is that checklist — the sections a trust center needs, why each one matters to a reviewer, and what a good version looks like.
The short version
Publish your controls, your compliance status, the documents reviewers ask for (some public, some gated), your subprocessors, and a vulnerability disclosure contact. Put a date on everything, and keep it at one URL you can send to every review. Want Notice Labs to host the page? See the security page product.
Security controls
A plain-language list of the safeguards that are actually running — access control, encryption, monitoring, backups, vendor review, incident response.
Why reviewers ask: It is the first thing a reviewer looks for and the fastest way to show there is a real programme behind the marketing.
What good looks like
- Written for a buyer, not lifted from a framework spreadsheet
- Grouped into a few categories (access, data, monitoring, vendors, incidents)
- Only controls that are running today, one plain claim each — no vague claims
- A visible “last reviewed” date so it reads as maintained
In Notice Labs, you choose controls from a library of standard wording, and the page shows a Last reviewed date that only moves when you mark it reviewed, so it can't go quietly stale.
Compliance and certifications
Which standards you hold, which you are working toward, and what each one actually covers.
Why reviewers ask: Buyers map your certifications to their own requirements. Ambiguity here creates a follow-up email; clarity closes the item.
What good looks like
- State the real status: certified, audit in progress, or aligned but not audited
- Name the report type (e.g. SOC 2 Type II) and the period it covers
- Do not imply a certification you do not have — reviewers check
- If you have nothing yet, say what you do have instead of hiding the section
A trust center is not a substitute for an audit. It communicates posture; it does not certify it.
Documents, and what to gate
The evidence a reviewer will ask for: SOC 2 or pentest reports, a DPA, security and privacy policies, an architecture overview.
Why reviewers ask: Handing these over one email thread at a time is slow and leaks. A page that offers them — some public, some on request — removes the back-and-forth.
What good looks like
- Public: privacy policy, security overview, subprocessor list, DPA template
- On request: SOC 2 report, penetration test summary, questionnaire responses
- An access request captures who is asking and why, with a quick approval
- Each document shows a date so nobody downloads a stale version
Notice Labs lets each document be public, available by request, or kept private, with requests handled in-app rather than over email. Create can build the security overview and a DPA template from what you've entered.
Subprocessors
The third parties that process customer data on your behalf: who they are, what they do, and where processing happens.
Why reviewers ask: It is a GDPR expectation and a standard diligence question. A maintained list also lets customers subscribe to changes instead of chasing you.
What good looks like
- Name, purpose, and processing region for each provider
- The data categories each one touches
- A clear last-updated date and a way to be notified of changes
- Only the subprocessors that are actually in use — no aspirational entries
The subprocessor directory is part of the Notice Labs page, not a paragraph buried in a policy PDF, and visitors who use Notify me are emailed when it changes.
Vulnerability disclosure
A named security contact and a short policy telling researchers how to report an issue and what to expect back.
Why reviewers ask: Without one, reports go to a sales inbox or nowhere. With one, you look like a team that takes security seriously.
What good looks like
- A dedicated address such as security@yourcompany.com
- What is in scope, and a basic safe-harbour statement
- A rough response time so reporters know they were heard
- Optionally a security.txt file pointing back to the page
Notice Labs gives every trust center a disclosure section with a contact that routes straight to the team you choose. The trust center also serves a security.txt that points to the form.
Data handling basics
A short account of what data you collect, where it is stored, how long you keep it, and how it is deleted.
Why reviewers ask: Privacy reviewers and security reviewers both ask this, and it is often the difference between a quick yes and a long questionnaire.
What good looks like
- Hosting location and region options, if you offer them
- Encryption in transit and at rest, stated once and plainly
- Retention and deletion timelines for customer data
- How customers can export or request deletion of their data
A route to ask questions
One obvious way for a prospect to reach a human about security, separate from the general sales flow.
Why reviewers ask: Every review eventually has a question your page did not answer. Make that easy so it does not stall the deal.
What good looks like
- A contact link or address specifically for security and diligence
- A clear owner internally, so answers are consistent
- A predictable turnaround, even if it is just “two business days”
Common mistakes
- A PDF last edited two years ago, emailed on request
- Claiming a certification that is really “in progress”
- A subprocessor list inside a policy nobody reads
- Security questions routed to the sales inbox
- No date anywhere, so buyers assume it is out of date
- A different link for every customer, none of them current
Questions worth asking
What people ask when they sit down to write the page.
What should a company security page include?
Your security controls, your compliance status, the documents reviewers ask for, your subprocessors, a way to report a vulnerability, and a short account of how you handle data. Put a date on it so it reads as maintained.
Is a security page the same as a trust center?
A security page covers your controls. A trust center holds that plus your compliance status, documents, subprocessors and intake forms, at one address you can send to every review.
Should we publish our SOC 2 report on the page?
Usually not openly. List the report on the page and make it available on request, so you know who is reading it and can approve each request. Public documents suit things like a privacy policy and a DPA template.
How often should a security page be updated?
Whenever a control, document, compliance status or subprocessor changes. Mark the page reviewed once you've checked it, so the date shows when someone last looked.
Do we need a vulnerability disclosure policy?
It's worth having one. Without a named contact, reports go to a sales inbox or nowhere. A short policy and a dedicated address tell researchers how to reach you.
Related reading
Publish the core sections in an afternoon.
From £39 a month. No sales call.