What has your company actually made public about its security? Every security review opens with the same three asks, GDPR Art. 28(2) makes one of them contractual, and the answers live in email attachments and ad-hoc page edits — a case for treating public security disclosure as a register you can enumerate, publish to deliberately, and retract from.
What has your company actually made public about its security? Every security review opens with the same three asks, GDPR Art. 28(2) makes one of them contractual, and the answers live in email attachments and ad-hoc page edits — a case for treating public security disclosure as a register you can enumerate, publish to deliberately, and retract from.
Every security review that reaches you opens with the same three asks: show your certifications, list your subprocessors, state your framework status. They arrive before the NDA, often before the first call, and each one's easy to answer on its own: someone forwards the certificate PDF, someone links the subprocessors page, someone pastes the framework summary into the buyer's portal. Have you ever tried asking the question the other way around? What exactly has your company made public about its security, who put each piece out there, and could you take any of it back? Try producing that list. If the answer is a folder of PDFs and a page-edit history, the list itself is the thing worth building. I want to convince you it needs exactly three properties.
The subprocessor ask has regulatory text directly underneath it. Let's read GDPR Art. 28, because it explains your subprocessor page. Art. 28(1) sets the controller's side of the relationship: "the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject." Buyer diligence in its current shape follows from that sentence: a controller that wants to use you carries a duty to check your guarantees before processing starts. That's why the questions arrive early and in writing.
Art. 28(2) sets the processor's side, and it's worth quoting in full:
"The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes."
Specific authorisation per change doesn't scale for a processor with hundreds of controllers, so data processing agreements observably settle on general written authorisation, which activates the second sentence. The public subprocessor page, with a change-notification mechanism behind it, is how teams in practice carry that information duty. Art. 28(3)(d) closes the loop: the contract itself must stipulate that the processor "respects the conditions referred to in paragraphs 2 and 4 for engaging another processor". Read together, the paragraphs make the subprocessor page the visible end of a contract chain, and its accuracy is what the chain assumes.
The other two asks have a supply-chain analogue in NIS2. Art. 21(2)(d) puts "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" on the minimum list of risk-management measures. Since NIS2 is a directive that lands on companies through national transposition, it reaches you mostly as your regulated customers' supplier diligence. The demand for disclosure is structural; it doesn't depend on any single buyer's thoroughness.
Let's look at how the answers actually ship. The certificate goes out as an email attachment. The subprocessor list lives on a CMS page that someone edits when a new vendor goes live, or a few weeks after. The report circulates under NDA and now sits in inboxes you don't control. Three properties are missing from this setup, and each one maps to a concrete failure.
First, nothing enumerates. Your public disclosure is the union of every page edit and every sent attachment, and no list of it exists anywhere. Reconciling the subprocessor page against the DPA appendix is manual diff work. That matters because the Art. 28(2) information duty assumes the published list tracks reality; a page nobody reconciles drifts away from the contract that references it, and the drift stays invisible because there's no register to check it against.
Second, publication is never an explicit act. A forwarded attachment is implicit publication: the circle of readers grows by one inbox per forward, and nobody performed an act you could point to afterwards. When "who decided this is public?" comes up, there's no decision on record. The file just moved.
Third, retraction doesn't exist. You can't unsend an attachment; a replaced page lingers in caches and web archives; a link that leaked keeps resolving. The operation you'd want on the day a certificate expires or a vendor is dropped — take this back, everywhere it's served from — has no implementation.
Here's the move: treat public security disclosure the way you already treat your asset inventory or your access list, as a register with defined properties, maintained on purpose. Three properties cover the failures above, so let's define them:
None of this decides what you publish. Whether a certificate file should be downloadable or only its existence stated, whether a subprocessor entry should carry detail beyond name and purpose — those stay judgment calls, made per item. A register gives you the inventory and the act; the policy is still yours. It doesn't require special tooling either: a reviewed table and a build step that renders it will do. What bothers me is the asymmetry: every other artifact your compliance program depends on (assets, access, risks) already gets this treatment, and public disclosure, the one artifact strangers actually see, mostly doesn't.
devguard ships this register as the Trust Center module, and I want to own the design decision behind it: we built the smallest register we could get away with, and we made it API-only on purpose. Here's how the three properties land, and what the minimalism costs.
Deliberate: the Trust Center ships switched off, and nothing becomes public until you enable it and publish items one by one. Exactly three kinds of things can be published: a framework adoption, a vendor acting as subprocessor, a certificate file. The same thing can't be published twice. Every publish, unpublish, enable and link rotation lands in the activity log with the name of the person who did it, so "who published it?" is a log query.
Enumerable: the public view is a list of the published items and nothing else — every piece of information it exposes is put there on purpose, and the admin preview shows exactly what the world would see.
Revocable: unpublishing removes the item immediately, and the public view re-checks validity every time it's read: archived vendors, deleted adoptions and expired certificates drop out on their own, because we'd rather show nothing than a stale SOC 2. The public link itself is an opaque handle, and if it leaks you rotate it: the new link works, the old one dies. A disabled register is also indistinguishable from a nonexistent one: an unknown link and a known-but-disabled one answer identically and reveal nothing.
The cost is real, and we chose it: the Trust Center is API-only. devguard serves the published data (frameworks, subprocessors, certificates) from a public endpoint under that opaque handle, and your website renders it. Headline, intro and any prose are yours; we don't store them. If you want a hosted trust page you can point procurement at without building anything, this isn't one, and that's deliberate: I think your public copy should go through whoever owns your public copy.
The question from the top — what has your company made public about its security? — should cost one query to answer, whatever you build the register with. It makes the three asks cheaper too: the review response becomes a link to the list plus the handful of items that need NDA handling, instead of a search through sent mail. And it gives the Art. 28(2) information duty something to attach to, because a list that changes on purpose can notify on purpose. If you're sitting on the buying side of the table this quarter, the same close-reading habit works in the other direction: see reading the Data Act's switching rights as a buyer.
The Trust Center is part of devguard's platform.
Angelo runs strategy and the relationships behind devguard. He spends his time with the teams who live with compliance day to day, and keeps what we build tied to what they actually need.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.