Most security pages are written to end a conversation. Ours is written on the assumption that a competent reader will use it to start one, and will notice what is missing.
The rule we settled on: a control goes on the page only if we can point at the code, the configuration or the test that implements it. Anything else is a plan, and plans go in a different section clearly labelled as such.
Things that pass the test
Tenant isolation is enforced by Postgres row-level security. Every tenant-scoped query runs inside a transaction that sets the current organisation first, and the policies filter from there. It passes the test because there is a dedicated integration suite that asserts a session scoped to one organisation cannot read another's properties, cannot insert into them, and cannot update them. That suite runs separately from the unit tests and against a real database, because a policy you have not tried to violate is a policy you are guessing about.
There are no long-lived cloud credentials. Deploys authenticate through Workload Identity Federation with short-lived tokens, and the absence of key files is verifiable by looking.
The notifications table is append-only at the database layer, which is why message metadata is written at insert rather than updated afterwards. That one is nice precisely because the constraint is visible in how the calling code is shaped; you can see the design being enforced.
Multi-factor authentication, rate limiting, standard security headers, and encryption in transit and at rest are all in the dependency list and the configuration. Unglamorous, checkable.
Things that do not, and why we say so
We are not certified against SOC 2 or ISO 27001. We could describe our practices as "aligned with" those frameworks, which is technically sayable and means nothing. An auditor has not looked. Saying so costs us nothing with serious buyers, who can tell the difference between a company without a certification and a company hoping you will not check.
Penetration testing is in progress rather than complete. What exists is an engagement brief, a scoping checklist and a remediation tracker, which is a real and reasonable position for a company our size, and is a different sentence from "penetration tested".
We keep a dependency risk register with dated audit output from before and after remediation passes. Publishing that we track known dependency risk is more informative than publishing that we have none, which nobody has.
Why the gap list is the more useful one
A control list tells a reader what you have thought about. A gap list tells them how you think: whether you know where your weaknesses are, whether you are honest about them under commercial pressure, and whether the roadmap is informed by risk or by whatever was easiest.
It is also the more durable claim. Control lists rot: something gets refactored, a control quietly stops applying, and the page keeps asserting it. A gap list ages in the right direction: items get closed, and closing one is a real event with evidence attached.
And it changes the sales conversation for the better. A buyer's security reviewer is going to find the gaps. The only question is whether they find them on your page or in a questionnaire response that contradicts it. The first costs you nothing. The second costs you the deal, and deservedly.
The failure mode we watch for
The risk in publishing a gap list is that it becomes a place to park things instead of fixing them. A gap that has sat unchanged for a year is not transparency, it is a written record of a decision nobody has revisited.
So the internal version of the list carries owners and dates, and the useful question at review is not "is this still true?" but "why is this still here?"