Public SaaS subprocessor benchmark: 8 pages scored
This is a pilot benchmark, not a gotcha list. The goal is to test one visible rubric against public subprocessor pages and see what a customer, founder, consultant, or attorney can actually learn without a login, trust-center request, or contract PDF.
Every score below is based on what was publicly visible on the review date. Private notices, gated trust centers, and contract-specific DPA terms may contain more detail than the public page shows.
Vendor names are easy, follow-through is not
All 8 pages named vendors and explained purpose, but none showed a public objection path and none showed a visible change-history trail.
You need a reality check before a rewrite
Use this pilot when you are deciding whether a public subprocessor page needs a cleaner notice flow, a better proof trail, or a deeper review packet.
Calibrate with the tracker or request teardown
Use the worksheet to score more pages, or send your page to NoticeKit for a short async gap read before you rewrite the workflow.
8 public pages reviewed
Reviewed on 2026-05-27 across AI, support, workflow, and developer-tool SaaS pages that were publicly accessible without login.
11.5 / 20
The middle of the sample was usable for vendor names and purpose, but still thin on customer follow-through details.
Objection path and change history
0 of 8 pages clearly described an objection window, customer-rights path, or visible archive of prior changes.
Vendor names beat workflow clarity
8 of 8 named vendors and 8 of 8 explained purpose, but only 2 of 8 clearly described how customers would be notified about future changes.
Top findings from the pilot sample
| Finding | What the sample showed |
|---|---|
| Vendor basics are usually present | All 8 pages listed named vendors and all 8 gave at least a basic purpose for each vendor or provider. |
| Scope detail is inconsistent | Only 4 of 8 pages clearly described data categories or processing scope well enough for a reviewer to rely on them. |
| Notice mechanics are mostly absent | Only 2 of 8 clearly described how customers would hear about future subprocessor changes. |
| Customer-rights follow-through is missing | 0 of 8 clearly described an objection window or customer-rights path on the public page itself. |
| Visible history is rare | 0 of 8 exposed a public archive, version history, or change log that would help a reviewer compare what changed over time. |
Scoreboard
| Company | Score | Band | Reviewed page | Short note |
|---|---|---|---|---|
| OpenAI | 12 / 20 | Thin | Sub-processor list | Strong vendor, purpose, and location detail, but no visible objection path, contact route, or public change history on the reviewed page. |
| Superhuman | 11 / 20 | Thin | Superhuman subprocessors | Purpose and country are clear and change notifications can be subscribed to, but data categories and change history are absent. |
| Inkeep | 10 / 20 | Thin | Inkeep subprocessors | Good vendor list with optional-model context and a visible update date, but weak public follow-through for notice, objection, and history. |
| Pylon | 9 / 20 | Thin | Pylon subprocessors | Clear table for name, purpose, and location, but little public detail about data scope, notice path, objections, or prior changes. |
| WipRadar | 14 / 20 | Adequate | WipRadar subprocessors | Compact page with update date, purpose, location, data categories, and legal contact, but no visible notice workflow or archive. |
| Foundable | 14 / 20 | Adequate | Foundable subprocessors | Strong processing-scope detail and a clear subprocessor versus independent-recipient split, but no visible objection workflow or public version history. |
| Cotool | 9 / 20 | Thin | Cotool subprocessors | Simple vendor, purpose, location, and contact listing, but no last-updated date, data categories, notice path, or archive. |
| AgentLattice | 14 / 20 | Adequate | AgentLattice subprocessors | Clear purpose, data-access, region, and enterprise-notification language, but no visible objection path or public history log. |
Band definitions follow the public methodology: 17-20 strong, 13-16 adequate, 9-12 thin, and 0-8 risky.
Score distribution and common gaps
Average score: 11.6 / 20. Median score: 11.5 / 20.
Open the appendix for the criterion-by-criterion point breakdown on every reviewed page.
What a founder should add before enterprise review
1. Add the workflow, not just the list
A vendor table is not the whole job. Say how changes are announced, where customers should ask questions, and what the next operational step is when a vendor changes.
2. Expose data scope in plain language
If a reviewer cannot tell whether a vendor handles logs, billing data, product content, or support data, the page still forces follow-up questions back into the sales thread.
3. Show the last update and preserve history
A visible date helps, but a visible archive is better. Without history, a reviewer still cannot tell what actually changed or whether the page is maintained consistently.
4. Keep the action path explicit
If there is a legal, privacy, or customer-success route for subprocessor questions, put it on the page instead of burying it in a separate trust-center or contract workflow.
Method and limits
This pilot uses the same 20-point rubric published in the NoticeKit benchmark methodology and tracker. Scores were assigned from public pages only. No gated trust-center material, private notices, or contract PDFs were used in the scoring.
The sample is intentionally small. It is enough to test the rubric and publish a concrete example, but not enough to claim market-wide averages. The broader 50-page benchmark still remains the target if this pilot produces useful buyer or advisor feedback.