Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →The sections that deflect real questionnaire volume, the ones that create liability, and the single rule that decides which is which.
One rule governs a trust centre and everything else follows from it: the page can only say what you can evidence. A framework with no report or certificate on file reads as readiness in progress, never as certified. Publish your honest compliance position, your subprocessor list, where data is held by region, your approved policy titles, your security contact and disclosure route, and a way to request the real documents under NDA. Do not publish findings, risks, readiness percentages, evidence, or any count that reveals a gap. A trust page that overstates the program is a misrepresentation to every buyer who reads it, and it is the first thing an auditor searches for.
A buyer's security review starts with an email that says "send me your SOC 2". A trust centre is the answer to that email, published once instead of written forty times. It states which frameworks are in play and where each honestly stands, who your subprocessors are, where data is held, how to report a vulnerability, and how to get the real documents under NDA.
The commercial case is deflection and speed. Some smaller buyers will complete their review from the page alone. Larger buyers will still send a questionnaire, but a shorter one, because their reviewer skips the sections your page already answered. And in every case the conversation starts from a stated position rather than from a blank, which changes the tone of the whole review. There is a broader introduction at what a trust centre is.
What a trust centre is not is a marketing asset. The temptation to write it like a landing page is strong and it is the origin of nearly every problem in this guide. The audience is a security reviewer whose job is to find the gap between what you claim and what you can show. Language that would be unremarkable on a product page reads to that person as either imprecision or evasion, and both cost you.
It is also not a replacement for the documents. The page tells a buyer what exists and how to get it. The report, the certificate, the policies and the test results go out under NDA, through a request that a human answers. That is a deliberate choice, discussed further below, and it is the correct one for almost every company.
The page can only say what you can evidence. Every editorial decision on a trust centre reduces to that sentence, and the discipline it requires is greater than it sounds, because the pressure to round up is constant and comes from people with good intentions.
Sales rounds up because a prospect asked and "in progress" felt weak. Marketing rounds up because the competitor's page says certified. A founder rounds up because the report is three weeks away and the deal closes on Friday. Each of those is an understandable impulse and each one produces the same artefact: a public claim that is not true on the day it is published.
The consequences are not theoretical. A claimed certification you do not hold is a misrepresentation to every buyer who reads the page, and unlike a wrong answer in a questionnaire it is made at scale, publicly, with your company name on it. It is also the first thing an auditor does when they start work: they search for you, read your public claims, and compare them against what you can produce. It is the kind of thing a readiness assessment raises as a critical finding, and it is a bad way to open an engagement.
The practical form of the rule is that every claim on the page should be traceable to a document you could produce within an hour. If you cannot name the artefact behind a sentence, the sentence does not go on the page.
The compliance section is where the page earns its keep and where it most often lies. A framework can honestly be in one of four states, and only the top one may use the words certified or attested.
Never publish a readiness percentage. A buyer reads "78% ready" as a grade, and it is not one; it is an internal measure of how much work remains against a control list you chose. It invites a question you cannot answer well, which is what the missing 22% is. Internally the number is useful. Publicly it is a hostage.
Never publish counts that reveal a gap. The number of open findings, the number of controls not yet met, the number of risks accepted, the number of overdue remediation items. Even good numbers are a mistake, because publishing a number commits you to publishing it next quarter, and the quarter where it moves the wrong way arrives eventually.
Never use the logo of a framework in a way that implies certification you do not hold. A SOC 2 badge on a page for a company in readiness is the same claim as the word certified, made in a form people find easier to defend internally and harder to defend externally.
Be careful with the word "compliant". SOC 2 is an attestation rather than a certification, and saying you are SOC 2 certified is a small error that tells a knowledgeable reviewer you may not have been through the process. There is a short explainer at whether SOC 2 is a certification or an attestation. ISO 27001 genuinely is a certification, and the thing to publish alongside it is the scope statement, because a certificate whose scope excludes the service the buyer is purchasing is a common and entirely legal disappointment.
Do not list frameworks you have merely considered. A row for HIPAA, PCI DSS and ISO 42001 all marked "in progress" on a company that has done work on none of them is padding, and it is transparent. List what is actually under way.
A SOC 2 report is not a public document. It contains a detailed description of your system, your control set, the auditor's tests, and any exceptions found, which taken together is an unusually good briefing for someone attacking you. It is also normally restricted by the terms of the report itself, which limits distribution to the entity, its customers and its prospects.
So the page does not host the report. It hosts a request route: a form or a named address that starts a conversation, gated on an NDA. That gate does two things. It keeps the document with parties who have accepted an obligation about it, and it tells you who is reading it, which is useful commercial information that a download link throws away.
Decide in advance what goes out at each stage, so the request is answered in hours rather than escalated. A workable default: the SOC 2 report or ISO certificate with scope statement, the penetration test executive summary, the policy set, the business continuity summary and the insurance certificate all go under a mutual NDA. Raw scan output, full penetration test findings, internal risk registers, audit working papers and incident records do not go at all.
Automated NDA-and-download portals exist and are convenient. They are also a decision to hand your report to anyone who clicks through a click-wrap agreement, including competitors and people doing reconnaissance. For most companies below a few hundred customers, a human answering the request within a business day is a better trade, because the volume is low and the qualification value is high. Revisit that when the volume genuinely hurts.
Between report periods you will be asked for a bridge letter, which is a short statement from you covering the gap between the end of the last report period and today. Mention on the page that one is available on request; it saves an email and it signals that you understand the mechanics. See what a SOC 2 bridge letter is.
This is the section buyers ask for by name, and it is the section most companies do not have. A subprocessor list names the suppliers that process your customers' personal data as part of you delivering your service, says what each one does, and says where they process it.
Three fields per row is enough: the supplier name, one plain sentence about what they do for you, and the processing region. "Sends transactional email" is the right level of detail. "Communications infrastructure" is not, because it does not let a privacy reviewer decide whether personal data reaches them.
Publish only what you need to. Names, purposes and locations. Never the agreements, never contract values, never your security assessments of them, never their criticality tier, and never the ones you have decided not to use.
The page needs a last-updated date and, if you can manage it, a subscription route so customers can be notified of changes. This is not decoration. Nearly every enterprise data processing agreement you sign commits you to maintaining a current list and to giving notice before adding a subprocessor, commonly thirty days. Publishing with a date and a notification mechanism is how you demonstrate you met an obligation you probably agreed to without reading closely. The mechanics are covered in the companion guide on the vendor DPA and subprocessor register.
The failure mode here is a list that goes stale. An engineer adds an observability vendor, it starts receiving stack traces containing user data, and the published list is silently wrong. Wiring the list to your actual vendor register, rather than maintaining it as a separate page somebody remembers to edit, is the only durable fix.
Publish the regions where customer data is stored and processed, at city and country level. Canadian buyers in the public sector, healthcare and financial services ask about residency early, and a specific answer on a public page removes a whole exchange of emails.
City and country, not street addresses. A trust page says where data is held, not where to find the building. A street number, a suite and a postal code on a public page is an invitation, and the person who typed the office address into a system was recording an operational fact rather than consenting to publish it.
Distinguish storage from processing from support access, because they are frequently different and the difference is exactly what a residency-sensitive buyer is asking about. Data stored in a Canadian region, processed in the same region, with support engineers accessing it from two other countries is a normal arrangement and a reasonable thing to state plainly. Stating only the storage region and being found out later is the avoidable version.
If you can commit contractually to a region for enterprise customers, say that the option exists. It is a genuine differentiator in Canadian enterprise and public sector sales and it costs nothing to mention.
Publish the titles of your approved policies and nothing else. The list demonstrates coverage, which is what the buyer is checking, and the titles alone tell a reviewer whether you have an access control policy, an incident response plan, a business continuity plan, a secure development policy and the rest.
The bodies go out under NDA. A policy document describes your internal controls in operational detail, sometimes names systems and roles, and occasionally contains configuration specifics. It is also a document you will revise, and a published version invites a buyer to hold you to language you changed a year ago.
Only list policies that are actually approved and in force. A published title with no approved document behind it is the same overclaim as a false certification badge, in a smaller font. If your policy set is half drafted, publish the approved half or publish nothing until it is done.
Some companies choose not to enumerate their policies publicly at all, on the grounds that the list maps their control coverage for anyone interested. That is a defensible position. It is a section worth treating as optional rather than mandatory.
A status page is a different artefact from a trust centre and the two should link to each other rather than merge. The status page reports current and historical availability, incidents and maintenance. The trust centre states your availability commitments and points at the status page for the record.
Publishing real uptime figures is a commitment with a long tail. Once a number is public, the quarter where it drops is public too, and buyers will ask about the gap. If you publish, publish the methodology alongside it: what counts as downtime, what is excluded, how it is measured, and over what window. An uptime figure with no methodology is not a number, and a sophisticated buyer will treat it as marketing.
Do not publish a service level number that your contracts do not actually offer. A trust page claiming 99.99% against contracts that commit to 99.9% has created an expectation gap that will eventually be argued about with money attached. There is more on the mechanics in the SaaS uptime SLA guide.
Incident history on a status page is an asset rather than a liability, provided the write-ups are honest and show improvement. Buyers do not expect zero incidents. They expect detection, communication and a fix, and a public record of exactly that is more persuasive than an unblemished page nobody believes.
A trust page with no way to report a vulnerability is the one omission a security researcher will hold against you publicly. Publish a monitored address, and publish a short disclosure policy that says what you commit to: that you will acknowledge within a stated time, that you will not pursue legal action against good faith research within stated boundaries, and what is out of scope.
Say what happens next. An acknowledgement window of two business days and a triage window of five is a reasonable commitment for a small company and is worth stating, because the alternative is a researcher escalating publicly after silence.
Publish a security.txt file at the standard location as well. It is a small file, it costs nothing, and it is where automated tooling and experienced researchers look before they look at your website.
Make sure the address is genuinely monitored, including during holidays. An unmonitored security address is worse than none, because it converts a private report into a public one at the point the researcher gives up.
Every sentence on the page describing a control is a statement you are now expected to be able to demonstrate, and it is read by at least four parties with different powers: prospective customers making a purchase decision, existing customers who may have contractual remedies, your auditor, and in some sectors a regulator.
The concrete effect is that a public control claim generates evidence obligations. If the page says access is reviewed quarterly, you now need four dated reviews a year with decisions recorded on them, indefinitely. If the page says you run an annual penetration test, the year you skip it is a year your public page is false. If the page says all data is encrypted at rest, the one legacy store that is not becomes a problem the day someone notices.
So write control claims at the level you can sustain rather than the level you achieved last quarter. "Access to production systems requires multi-factor authentication" is durable. "All employee accounts across all systems require hardware security keys" is a claim about a state you will have to police forever, and one contractor with a phone-based authenticator makes it false.
The same logic applies to anything time-bound. A page that says "reviewed quarterly" needs the review to have happened this quarter. Prefer claims about mechanisms over claims about frequencies where you have the choice, and where you do state a frequency, put it on the compliance calendar the same day you publish it.
Contractual exposure is the part people miss. Many enterprise agreements incorporate your published security documentation by reference, which converts your trust page from marketing into a schedule of the contract. Have someone read it with that in mind before it goes live.
The characteristic failure is not a deliberate lie. It is a page written once, by someone in marketing, from a description of the program as it was intended to be, and then never revisited. Six months later the company has genuinely improved and the page is still wrong, in ways nobody has read closely enough to notice.
It usually shows up in one of four ways. A framework marked certified when readiness is under way. A policy list including documents still in draft. A control claim in the present tense describing something that ran once. And a subprocessor list missing the two vendors added since it was written.
The cost lands at the worst moment. A buyer's reviewer reads the page, requests the report, compares them, and finds the page says more than the report supports. That is no longer a security review; it is a credibility problem, and it is very hard to recover inside the same deal. Alternatively an auditor finds it during fieldwork, and a public misstatement about the control environment is not a small conversation.
The structural fix is to derive the page from the same records that hold your evidence, rather than writing it as prose. A page that reads its compliance status from whether a report is actually on file cannot claim a certification you do not hold, because there is nothing for the claim to be made out of. Where that is not possible, the fallback is an owner, a review date, and a rule that the page is re-read every time a report is issued, a policy is approved, or a subprocessor changes.
Give the page one owner, usually whoever owns the compliance program rather than whoever owns the website. Marketing can own the layout. They should not own the claims.
Review it on a fixed cadence, quarterly is sufficient, and on four triggers: a report or certificate is issued or expires, a policy is approved or retired, a subprocessor is added or removed, or a control described on the page changes. The trigger list matters more than the cadence, because the things that make the page false are events rather than the passage of time.
Before it goes live the first time, check three things. There is a monitored security contact, because a trust page with no disclosure route is the one thing a researcher will hold against you. Every framework state matches a document you can actually produce. And nothing on the page reveals a gap: no counts, no percentages, no findings, no risks.
Link it from where buyers look. The footer, the security section of your website, your sales collateral, and the automatic reply to your security address. A trust centre nobody can find deflects nothing, and the most common reason these pages fail to reduce questionnaire volume is that the questionnaire arrived from someone who never saw it.
Finally, measure whether it is working. Two numbers: the proportion of inbound security requests that ask for documents rather than send a spreadsheet, and the number of questions per questionnaire that the page had already answered. If neither moves in six months, the page is either too thin or too well hidden. The trust centre builder is a reasonable way to draft the first version.
| Artefact | Where it goes | Why, and what to watch |
|---|---|---|
| Framework status | Publish | One of four states: report on file, expired, audit under way, readiness in progress. Only the first may say certified or attested. |
| SOC 2 report | Under NDA | Contains your system description, control set, tests and exceptions. Distribution is normally restricted by the report itself. Never a public download. |
| ISO 27001 certificate | Publish or under NDA | The certificate itself is often shareable. Publish the scope statement with it, because a certificate whose scope excludes the purchased service misleads by omission. |
| Policy titles | Publish, optional | Demonstrates coverage. Only list approved, in-force documents. Some companies reasonably choose not to enumerate their control coverage at all. |
| Policy documents | Under NDA | Operational detail, named systems and roles, and language you will revise. Publishing invites being held to a version you have since changed. |
| Subprocessor list | Publish | Name, one sentence of purpose, processing region. Add a last-updated date and a notification route, because your customer contracts probably require both. |
| Data locations | Publish | City and country, not street addresses. Separate storage, processing and support access, because those are what a residency question is really about. |
| Penetration test summary | Under NDA | Scope, methodology, dates, severity distribution and remediation status. The full report with live findings is a map of how to attack you. |
| Uptime figures | Publish with care | Only with the methodology beside them, and never above what your contracts commit to. Once published, the bad quarter is published too. |
| Incident history | Publish on the status page | Honest write-ups showing detection, communication and fix are persuasive. An unblemished page nobody believes is not. |
| Security contact and disclosure policy | Publish | Mandatory in practice. Add a security.txt file. An unmonitored address is worse than none, because it converts a private report into a public one. |
| Insurance certificate | Under NDA | Frequently requested in enterprise reviews. Share the certificate, not the policy schedule with your limits and exclusions in it. |
| Readiness percentage | Never | An internal work measure that a buyer reads as a grade. Publishing it invites a question about the remainder that has no good answer. |
| Findings, risks, open remediation | Never | Includes counts. Even a good number commits you to publishing it next quarter, and the quarter it moves the wrong way arrives eventually. |
| Audit evidence and working papers | Never | Configuration exports, access listings, ticket samples. These go to your auditor, not to buyers, and never to the public internet. |
No. Until a report is issued and on file you have no attestation, and saying otherwise is a misrepresentation to every buyer who reads the page. What you can say, and what reads as strong precisely because it is specific, is that the audit is under way with the observation window running between named dates and a report expected in a named quarter. That is falsifiable, which is why reviewers find it credible. It is also worth noting that SOC 2 produces an attestation rather than a certification, so the phrase SOC 2 certified signals to a knowledgeable reviewer that you may not have been through the process.
Not for most companies. The report describes your system, your control set, the tests performed and any exceptions found, which makes it a good briefing document for someone attacking you, and its distribution is normally restricted by the terms of the report itself. Publish a request route gated on an NDA instead. That keeps the document with parties who have accepted an obligation about it and tells you who is reading it, which a download link throws away. Automated click-through NDA portals are convenient at high volume and are a decision to hand the report to anyone who clicks, competitors included.
In practice yes, because your customer contracts almost certainly require it. Nearly every enterprise data processing agreement commits the vendor to maintaining a current list of subprocessors, making it available, and giving notice before adding new ones, commonly thirty days. Companies routinely agree to this without registering that they have. Publishing the list with a last-updated date and a way for customers to be notified of changes is the cheapest way to demonstrate the obligation is met. Three fields per row is enough: name, one sentence of purpose, and processing region.
Two things, and both are expensive. A buyer requests the report, compares it to the page, and finds the page claims more than the report supports, which turns a routine security review into a credibility problem that is very hard to recover inside the same deal. Separately, an auditor searches for your public claims at the start of fieldwork and compares them to what you can produce, and a public misstatement about the control environment is not a small conversation.
Only with the methodology beside them, and only if your contracts support the figure. Publishing an availability number is a commitment with a long tail, because the quarter where it drops is public too and buyers will ask about the gap. State what counts as downtime, what is excluded, how it is measured and over what window. Do not publish a figure higher than what your service level agreements actually commit to, because that creates an expectation gap that eventually gets argued about with money attached.
It reduces them, it does not remove them. Smaller buyers sometimes complete their review from the page alone. Larger buyers still send a questionnaire, but a shorter one, because their reviewer skips the ground the page already covers, and the conversation starts from a stated position rather than a blank page. Measure two things after six months: the proportion of inbound requests that ask for documents rather than send a spreadsheet, and how many questions per questionnaire the page had already answered. If neither has moved, the page is either too thin or too well hidden.
Whoever owns the compliance program, not whoever owns the website. Marketing can own the layout and the design. They should not own the claims, because the claims are statements about the control environment and they generate evidence obligations. Review the page quarterly and on four triggers: a report or certificate is issued or expires, a policy is approved or retired, a subprocessor changes, or a control described on the page changes. Those events are what make the page false, rather than the passage of time.
To being able to demonstrate it, indefinitely, to prospective customers, existing customers with contractual remedies, your auditor and in some sectors a regulator. If the page says access is reviewed quarterly you now owe four dated reviews a year with decisions recorded on them. If it says you run an annual penetration test, the year you skip one is a year your public page is false. Many enterprise agreements also incorporate published security documentation by reference, which turns the page into a schedule of the contract. Write claims at the level you can sustain rather than the level you hit last quarter.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We build the page from the evidence you actually hold, so the compliance claims on it are ones your report and your registers will support.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.