The Trust Page Written Entirely in Future Tense

Category: Customer Trust & Third-Party Risk Tags: trust center, dogfooding, compliance program, GDPR, SOC 2, transparency, roadmap

Read enough vendor trust pages and you start noticing the tense. We are committed to protecting your data. We are pursuing SOC 2. Security is embedded in everything we do. Our roadmap includes a formal privacy program. Every sentence is either a feeling or a future, and not one of them contains a date, a scope, or an artifact you could ask for. The page exists so that a sales team can send a link when a security review starts, and it works exactly once, which is until somebody reads it closely.

The version of this I find least forgivable is when it appears on the site of a company selling security or governance. If your product is a control framework and your own trust page is written in the conditional, you have published a review of your own seriousness. I have sent questionnaires to GRC vendors and received answers I would have rejected from a logistics supplier, and the tell was always the same: fluent language about posture, nothing that could be checked.

So here is ours, in present tense, including the parts that are unimpressive. PivotRisk is building a hosted platform that will hold customer data, and we decided to stand up our own compliance program before that platform ships rather than after a customer asks. We are running it on our own templates, and we are going to write up what happens, including what the templates get wrong.

What We Actually Are Today

The honest starting position is that our current risk surface is small, and describing it precisely is more useful to a reader than a badge would be. This site is static. The pages you are reading are files served directly from storage, and there is no application behind them, no login, no account, and no customer database, because there is no product here that requires one.

Two things do run. The contact and newsletter forms post to a small serverless function whose only job is to send an email, and it has no database attached to it, no key-value store, and no storage binding of any kind, which means the submission is delivered to a mailbox and nothing is retained by the site itself. And the risk map runs entirely in your browser: it fetches nothing at all until you press the button, no PivotRisk server sits in the path of those requests, and nothing you type into it is stored or transmitted to us. The honest corollary, which belongs on a trust page rather than in marketing copy, is that when you do press the button your browser talks to those publishers directly, so they see a request from you and we see nothing.

The paid templates are files. Twelve of them, bought and downloaded, which means the workbook that runs your risk register runs on your machine rather than ours. That is a deliberate product decision and it is also, right now, our largest single piece of privacy engineering: the data stays where it was created.

None of that is a compliance program. It is an inventory, and it is the first artifact any program needs, which is why I am leading with it rather than with a framework name.

What Changes the Day the Platform Ships

Everything in this section is roadmap, and I want that stated plainly rather than implied by a verb tense, because this is exactly where trust pages start lying. None of the following exists today.

The paid version of the risk map is being built as a hosted, multi-tenant application, and it changes our posture completely. It will hold client site and vendor data, and for the duty of care capability it will hold information about where employees are, which is personal data of people who are not our customers and never agreed to anything with us. That is a serious obligation, and the design constraints follow from it: tenant isolation as an architectural property rather than a query filter, a managed identity provider so we are not inventing authentication, data minimization at collection, regional residency options, and working export and deletion endpoints from the first release rather than the first request. We are designing against GDPR, SOC 2, and the NIST Privacy Framework from the start, which means the controls are being built into the thing rather than reconstructed under audit pressure eighteen months later.

What I am not going to do is put any of that in the present tense before it is true, or name a certification date we have not booked. When a control is real it gets described with the date it became real. Until then it is a plan, and plans are worth publishing as plans.

Why We Are Using Our Own Templates

The obvious reason to run our program on the templates we sell is that it would be embarrassing not to. The better reason is that it is the only honest test any of them will ever get.

A template that has only ever been used to produce example content is a hypothesis. Used on a real program with real constraints, it either carries the work or it does not, and the ways it fails are specific: a field nobody can populate without inventing something, a scoring rule that produces a rating you cannot defend, an assumption about team size that collapses at one person, a mapping that turns out to be aspirational. I expect to find several of those. When I do, the fix goes into the product and the finding goes into an article, because a template that has been broken against reality and repaired is worth more than one that has never been tried, and pretending the first pass was clean would be its own small version of the future-tense trust page.

This also puts us in the position I described in you are somebody else's third party. We are about to become a vendor holding other people's data, assessed by risk teams running the same process we teach, and the fastest way to understand what that feels like is to complete our own assessment about ourselves before anyone else does it for us.

The Rules This Series Runs Under

Four rules govern what gets published here, and they are worth stating up front so you can hold us to them. Every claim about PivotRisk is verifiably true at the moment it is published, which is why the inventory above describes storage bindings that do not exist rather than a security posture that sounds strong. Anything not yet built is labeled roadmap in the same breath, not softened into an implication. Controls that become real get a date attached, because an undated claim is a claim you cannot audit, which is the entire argument of risk intelligence you cannot audit applied to ourselves. And findings get published even when they make the product look worse in the short term, since a compliance program you only report on when it goes well is a marketing campaign wearing a program's clothes.

There will also be a trust page, and it will be a reference page rather than a series of essays: the security overview, the subprocessor list, the data handling and retention answers, the documents available on request, each with a date. These articles are the working detail behind it, not a substitute for it. A security reviewer who lands on our site mid-evaluation with one specific question deserves an answer in one scroll, not a reading list.

The reason to do any of this in public is not that transparency is virtuous. It is that we sell the argument that a control you cannot evidence is a hope and a rating you cannot reconstruct is an opinion, and a firm making that argument while keeping its own program behind a page of adjectives is not credible. If we get this wrong somewhere, the right response is to tell us, and we would genuinely rather hear it from a practitioner reading this than from a customer's auditor a year from now. That is roughly the standard we would apply to a vendor. It seems fair to be held to it.