A trust center for your SaaS: the page procurement wants to see

The demo went well, your champion in the business unit is convinced, the budget is approved. Then procurement gets in touch: a security questionnaire with dozens of questions, plus a request for your data processing agreement. From that moment on, it is no longer your product that decides the deal — it is your response speed.

The questions rarely surprise anyone. Four blocks show up in practically every questionnaire:

The answers already exist in your company. They are just scattered: across Confluence pages, in email attachments, in your CTO's head. Every round of searching and aligning costs days, and if the sign-off from the data protection officer on the customer side takes its time, the deal slips into the next quarter.

This is exactly where a trust center comes in: a public page that answers these questions before anyone asks them. While your trial funnel optimizes for self-service, the trust page sells to the people who never create a test account: procurement, IT security, data protection. It is one chapter in our series on the anatomy of a B2B SaaS website.

One note before we start: I am not a lawyer, and this article is not legal advice. It is about feasibility — about presenting the evidence you have to provide anyway in a way that shortens review loops.

For orientation: in my experience, five building blocks cover most of any security questionnaire. The table shows which procurement question each block answers; I will then go through them one by one.

The data processing agreement under Art. 28 GDPR is, in my experience, the most requested document in B2B SaaS sales. As soon as you process personal data on behalf of your customers, it is mandatory, not optional. Offer it directly: as a PDF with a version date to download, or as part of the contract with click-to-accept in your order process.

The difference shows up in day-to-day sales as email loops: a DPA “on request” creates at least one round of waiting per deal. A DPA available for download signals the opposite: we know our obligations, and we have been through this process many times.

For larger deals, a two-tier model has proven itself: a standard DPA with click-to-accept for self-service customers, and a countersignable version for corporations whose procurement insists on signatures. Both versions belong on the trust page, each with a visible version date.

Your hosting provider, your email service, your support tool: every service that processes your customers' personal data on your behalf is a sub-processor. Under Art. 28(2) GDPR, you need your customers' prior written authorisation to engage them; with the usual general authorisation, you must inform them of intended changes and give them the right to object.

A public list with name, purpose and processing location therefore does two jobs at once: it answers the questionnaire question, and it is the reference point for your change notifications.

“Where is our data stored?” is often the first question in DACH sales (Germany, Austria, Switzerland), ahead of any certificate. Answer it in one sentence: provider, region, redundancy where relevant. “Hosted on AWS in the Frankfurt region” beats any evasive phrasing about global cloud infrastructure.

One important point: the location of your application alone is not enough. Reviewers look at the whole chain, including where your sub-processors process data. An EU region is of little use if your support tool mirrors tickets, customer data included, to the US.

ISO/IEC 27001 is the internationally authoritative standard for information security management systems. For your trust page, currency is what counts: since 31 October 2025, certificates issued against the 2013 version are invalid; only ISO/IEC 27001:2022 applies, with 93 controls in Annex A instead of the previous 114. An outdated certificate badge is something auditors notice immediately.

SOC 2 comes from the US and convinces above all corporations with international procurement. In the DACH market, the report does no harm, but it replaces neither the DPA nor your technical and organisational measures. And if you have no certificate yet: show what you have. A pentest summary, your encryption concept and your backup procedure are more than many competitors publish.

Availability is the piece of security evidence that even non-lawyers understand immediately. A public status page with incident history proves two things: that your service runs reliably and that you communicate openly when things break. Link it prominently from the trust page. Contractually guaranteed availability, on the other hand, belongs in the SLA — the status page documents, the SLA obligates.

For context: US templates treat the trust center primarily as a SOC 2 showcase. In the German-speaking market, however, the first reviewer is rarely an auditor — it is a data protection officer. Three points decide approval here.

Art. 28(3) GDPR lists eight mandatory contents for the contract in points (a) to (h): among them processing only on documented instructions, confidentiality obligations, security measures under Art. 32, rules for sub-processors, support with data subject rights, and deletion or return of the data once the contract ends.

In practice this means: provide your own template DPA instead of waiting for your customers' templates. Whoever presents their own document negotiates on familiar ground, keeps their clauses consistent across all customers and saves lawyer hours on both sides.

The technical and organisational measures are the annex that almost every DPA references. Art. 32(1) GDPR names as examples the pseudonymisation and encryption of personal data, ensuring the ongoing confidentiality, integrity, availability and resilience of systems, rapid recovery after incidents, and a process for regularly testing the measures.

Write your measures concretely: the encryption methods in use, backup intervals, access concept, offboarding process. Any data protection officer recognizes a TOM document made of generic boilerplate at first glance — and then asks all the more questions.

Third-country transfers are the point where data protection reviews escalate most often. If your SaaS runs in an EU region and your sub-processors process data there too, say so prominently: on the trust page, in the DPA, in the sub-processor list. A compliance footnote becomes a differentiator against US competitors.

Be honest about it: if individual services process data outside the EU, name them along with the safeguards instead of hiding them in footnotes. A reviewer who finds a gap on their own checks twice as carefully afterwards.

Condensed into one sentence: procurement does not buy features, it buys the absence of risk.

I looked at how German SaaS providers present their security evidence, as of September 2026. Three patterns stand out.

The Munich-based HR provider runs its own trust center at trust.personio.com. Publicly visible are the certificates for ISO/IEC 27001:2022 and ISO/IEC 27017 as well as the document list: technical and organisational measures, DPA, pentest report, business continuity plan. The sensitive documents themselves sit behind a “Get access” step. The pattern: maximum visibility of the evidence, controlled release of the details.

The employee communications provider from Chemnitz answers the location question directly on its security page: customers choose between data centers in the EU (Frankfurt, on Azure and AWS), in the US and in Australia. On top of that come ISO 27001, SOC 2, a GDPR-compliant DPA and a dedicated sub-processor subpage. The pattern: the hosting location is not a footnote but a selectable product feature.

The accounting SaaS from Offenburg shows that it works without ISO 27001 too: its security page lists a TÜV Saarland certification for data protection, external penetration tests and the deliberately chosen server location Germany, on AWS. If you have no ISO certificate yet, ground your promise with location and independent audits.

Striking across all three: none of these pages sells features. They answer review questions — each at its own maturity level.

The most common mistake comes after launch: the trust page goes stale. The certificate expires, the sub-processor list no longer matches the DPA, the TOM PDF carries a date from three years ago. Exactly the signals that cost trust instead of building it.

My recommendation: treat the content as structured data in your CMS, not as uploaded PDFs. In our stack of Next.js and Sanity, the sub-processor list is one record per service with name, purpose, location and review date; the page renders a table and a change history from it. A mandatory “last reviewed” field enforces the maintenance rhythm.

Also define who owns the page and how often it is reviewed: once per quarter is usually enough, plus ad hoc whenever a new tool enters your stack. That way, the change notification to your customers becomes a by-product of maintenance rather than a fire drill.

The side effect pays off twice: the same structured data feeds your questionnaire answers. And because AI assistants read along when buyers pre-screen vendors, a machine-readable trust page works in that channel too.

Start with an inventory along the five building blocks: what do you already have, what is missing? You can get the DPA, the sub-processor list and the hosting statement online without a certification project, often within a few weeks. The certificate can follow.

If you would like support along the way: as a B2B website agency, we design and build trust centers as structured CMS content that gets maintained instead of going stale. Book a free initial consultation — we will look at your security track together and prioritize what helps your sales team fastest.