SaaS Ranking

Blog

What 8,449 SaaS companies publish before the sales call

Twelve disclosures a buyer needs before signing, measured at 8,449 companies: which we found often, which rarely, and where the gap is ours.

Published · 2,046 words · by SaaS Ranking

The short answer

Mostly the settings, rarely the contracts. Of the twelve disclosures we check, one was found at more than half of the companies we could measure: HTTPS enforced with HSTS, at 5,140 of 8,310 (62%). Public pricing and a named privacy contact follow at 37% and 36%. The two documents that say who processes a customer's data and on what terms were found far less often: a data processing agreement at 819 of 7,941 companies (10%), a subprocessor list at 530 of 7,934 (7%). The median transparency score across all 313 categories is 17 out of 100.

Every figure here comes from one snapshot, r72.102956: 102,956 source-backed results from run 72 and earlier, newest measurement 2026-09-13, read from the live pages on 2026-09-13. The site measures again every night, so these numbers will move. The commands that pull the current ones are at the end, and a figure quoted from this piece carries its date.

The snapshot behind this piece. 8,449 companies, 12 disclosures checked, 102,956 source-backed results, 17 / 100 median score, 313 categories, 2026-09-13 newest measurement. 8,449 companies 12 disclosures checked 102,956 source-backed results 17 / 100 median score 313 categories 2026-09-13 newest measurement
Figure 1. The snapshot behind every number in this piece: 8,449 companies behind 8,453 vendor profiles, 12 disclosures, snapshot r72.102956.

A company here is a domain. 8,453 vendor profiles belong to 8,449 companies, because a few companies appear with more than one product. Rankings count profiles; this piece counts companies unless it says otherwise.

Each disclosure is looked for at a fixed list of addresses derived from the vendor's domain: eight for the data processing agreement, seven for the subprocessor list, one for security.txt. Two checks are our own measurements rather than document finds: whether plain HTTP redirects to HTTPS with an HSTS header, and whether the front page, loaded once in a browser, makes third-party requests before anything is clicked. The crawler never logs in, accepts no NDA and submits no form, and every address it fetches is public. What this measures is what a vendor shows to someone who has not spoken to sales.

The twelve disclosures, by how often we found them

Each share is computed against the companies we could measure for that criterion, not against all 8,449. A company we could not reach falls out of the numerator and the denominator, so an outage on our side never lowers anyone's number.

Share of the companies we could measure at which each disclosure was found. HTTPS enforced with HSTS: 62%, 5,140 of 8,310; Public pricing: 37%, 2,952 of 7,943; Named privacy contact: 36%, 2,847 of 7,896; Certifications named: 24%, 1,899 of 7,974; Data location stated: 24%, 1,879 of 7,949; Status page with history: 18%, 1,455 of 8,017; security.txt (RFC 9116): 11%, 814 of 7,690; Data processing agreement: 10%, 819 of 7,941; Notice before subprocessors change: 9%, 734 of 7,873; Subprocessor list: 7%, 530 of 7,934; No third-party tracking before consent: 6%, 482 of 8,259; Uptime SLA with a figure: 3%, 273 of 7,865. HTTPS enforced with HSTS 62%, 5,140 of 8,310 Public pricing 37%, 2,952 of 7,943 Named privacy contact 36%, 2,847 of 7,896 Certifications named 24%, 1,899 of 7,974 Data location stated 24%, 1,879 of 7,949 Status page with history 18%, 1,455 of 8,017 security.txt (RFC 9116) 11%, 814 of 7,690 Data processing agreement 10%, 819 of 7,941 Notice before subprocessors change 9%, 734 of 7,873 Subprocessor list 7%, 530 of 7,934 No third-party tracking before consent 6%, 482 of 8,259 Uptime SLA with a figure 3%, 273 of 7,865
Figure 2. Where each disclosure was found, as a share of the companies we could measure for it. The grey track is 100%, and every bar is drawn at its unrounded share. Snapshot r72.102956.

Three things stand out. Only one disclosure clears fifty percent, and it is a server setting, not a document. The three heaviest criteria carry 3 of 23 points each, and two of them, the agreement and the subprocessor list, are found at 10% and 7%; the third, the data location, at 24%. And four of the twelve were found at fewer than one company in ten, the rarest being an uptime SLA with a figure: 273 of 7,865 (3%).

All twelve disclosures with their weight, the number of addresses checked and the figures behind Figure 2 and Figure 3.
DisclosureWeightAddressesFoundMeasuredShareNot reached
Data processing agreement 3 8 819 7,941 10% 508
Subprocessor list 3 7 530 7,934 7% 515
Data location stated 3 7 1,879 7,949 24% 500
Status page with history 2 3 1,455 8,017 18% 432
Public pricing 2 5 2,952 7,943 37% 506
Certifications named 1 6 1,899 7,974 24% 475
Uptime SLA with a figure 1 6 273 7,865 3% 584
HTTPS enforced with HSTS 2 2 5,140 8,310 62% 139
No third-party tracking before consent 2 1 482 8,259 6% 190
security.txt (RFC 9116) 1 1 814 7,690 11% 759
Notice before subprocessors change 2 8 734 7,873 9% 577
Named privacy contact 1 7 2,847 7,896 36% 554

The criteria overview shows the same columns for the snapshot the site is serving today.

Where the gap is ours

For every criterion there are companies at which we could not measure at all: no address answered, the server blocked or rate-limited us with a status such as 403 or 429, or robots.txt asked us to stay away from an address. That describes our crawler and not the vendor. It is recorded as not measured, never as a negative, and it sits outside every percentage above.

Share of all companies at which we could not measure each disclosure. security.txt (RFC 9116): 9%, 759 of 8,449; Uptime SLA with a figure: 7%, 584 of 8,449; Notice before subprocessors change: 7%, 577 of 8,449; Named privacy contact: 7%, 554 of 8,449; Subprocessor list: 6%, 515 of 8,449; Data processing agreement: 6%, 508 of 8,449; Public pricing: 6%, 506 of 8,449; Data location stated: 6%, 500 of 8,449; Certifications named: 6%, 475 of 8,449; Status page with history: 5%, 432 of 8,449; No third-party tracking before consent: 2%, 190 of 8,449; HTTPS enforced with HSTS: 2%, 139 of 8,449. security.txt (RFC 9116) 9%, 759 of 8,449 Uptime SLA with a figure 7%, 584 of 8,449 Notice before subprocessors change 7%, 577 of 8,449 Named privacy contact 7%, 554 of 8,449 Subprocessor list 6%, 515 of 8,449 Data processing agreement 6%, 508 of 8,449 Public pricing 6%, 506 of 8,449 Data location stated 6%, 500 of 8,449 Certifications named 6%, 475 of 8,449 Status page with history 5%, 432 of 8,449 No third-party tracking before consent 2%, 190 of 8,449 HTTPS enforced with HSTS 2%, 139 of 8,449
Figure 3. The gap on our side: companies at which we could not measure that criterion, as a share of all 8,449. The track is 100%, as in Figure 2. Grey, because it describes our reach and not a finding.

The gap runs from 139 companies (2%) for HSTS to 759 (9%) for security.txt. A document check counts as not measured when none of its addresses could be read, so a check with one address ends at the first blocked request, and security.txt has one. The two checks that ask for the front page have the smallest gaps, 139 and 190.

For ten of the twelve criteria, measured and not reached add up to exactly 8,449. For the notice before subprocessors change and the named privacy contact they add up to 8,450. The cause is a company with more than one product: it counts as measured if we could measure one of them and as not reached if we could not measure another.

How a result gets its state

A result has three states, not two, and the third keeps a negative honest. The ten document checks decide in the order below; for the two checks that are our own measurements, a failed load is likewise not measured and never not found.

How a document check gets one of its three states. Fetch the fixed addresses of one criterion. Recognised at any address? If yes: found, with the address. Behind a sign-in at an address? If yes: not published openly. An address excluded by robots.txt? If yes: not measured. Was any address reached? If no: not measured; if yes: not found at the addresses checked. Fetch the fixed addressesof one criterion Recognised atany address? yes found, withthe address no Behind a sign-inat an address? yes not publishedopenly no An address excludedby robots.txt? yes not measured no Was any addressreached? no not measured yes not found at theaddresses checked
Figure 4. The order in which a document check decides. "Reached" means an answer other than a network error or a blocking status such as 403, 429 or 503. "Not measured" describes us and falls out of every percentage; "not found" means we read the site and recognised the document at none of the addresses we checked.

A find comes with its address and its date. A result that is not found comes with every address we checked and what each returned, on the vendor's profile and in its evidence pack. A document behind a sign-in counts as not published openly, because that is what the criterion asks, and the result says so. Every result that is not found or not measured carries a link to send us the right address; a person reads it, and a vendor with an open correction moves into the next nightly run.

One consequence for the figures above: a vendor we could measure on fewer than nine of the twelve criteria gets no score and no rank, rather than a low one. 582 vendor profiles in this snapshot are in that position and appear in no band and no median.

How the scores are distributed

The transparency score is the share of weight found among the criteria we could measure for a vendor; the twelve weights add up to 23, and they are set out on the methodology page. It is shown as a band with fixed thresholds: A from 85, B from 70, C from 55, D from 40, E from 25, F below 25.

Vendors with a score, by band. A: 6, B: 109, C: 220, D: 575, E: 1,688, F: 5,273. 6 A 0.1% 109 B 1.4% 220 C 2.8% 575 D 7.3% 1,688 E 21.4% 5,273 F 67.0%
Figure 5. 7,871 vendors with a score, by band; 582 more carry no score. Column heights are proportional to the count, so band A with 6 vendors is a line rather than a column. The colours are the band colours used on every label.

5,273 of 7,871 vendors with a score (67%) are in band F and 6 are in band A. Only 910 (12%) reach band D or better, so a score of 40 already places a vendor in that group. Keep that in mind before reading any single ranking. It is also why the front page shows the vendor closest to the median as its example and never the one at the top: with a median of 17, a leader would read as a recommendation, and this site makes none.

A worked example: a CRM shortlist

CRM is the largest category we measure: 109 vendor profiles, median score 17, the same as the market median. We asked the explorer one question on 2026-09-13 and added one condition at a time.

CRM vendor profiles matching each added condition in the explorer. CRM vendor profiles: 109 of 109; Data processing agreement found: 14 of 109; and subprocessor list found: 2 of 109; and EEA named for hosting: 0 of 109. CRM vendor profiles 109 of 109 Data processing agreement found 14 of 109 and subprocessor list found 2 of 109 and EEA named for hosting 0 of 109
Figure 6. What the explorer returned for CRM as conditions were added, snapshot r72.102956. Each bar is the number of vendor profiles at which we found everything above it.

At 14 of the 109 we found a data processing agreement, at 2 both the agreement and a subprocessor list, and at none all of that plus the European Economic Area named as a hosting location. That last figure describes our measurement and nothing else: a vendor can host in the EEA and say so on a page we do not fetch, in a sentence our reader does not count, or in a contract behind a sign-in. For a shortlist it means the review starts with a question to the vendor. The steps work for any category.

  1. Pick the category and the documents that decide your review. On the explorer, tick the criteria you need. Every condition is something we found; there is no "without" filter, because not finding a document is not the same as its absence.
  2. Add the value your policy needs. A hosting location or a certification, for example. The values on offer are ones we read on vendor pages, each backed by its sentence.
  3. Read a missing vendor as an open question. We did not find everything at the addresses we checked; its evidence pack lists those addresses and what each returned.
  4. File the evidence. Every profile offers its results as CSV and JSON, each row with the date and the snapshot identifier.
  5. Check again before you sign. The changes page lists what moved between runs.

Questions buyers ask

Is "not found" a statement about the vendor?

No, it is a statement about our measurement. On the date given, we did not recognise the document at any of the addresses we checked, and those addresses are listed. The document may sit behind a login, at an address we do not try, or in a trust portal that asks for an NDA.

Why is the denominator different for every criterion?

Because "not measured" is left out of both sides. For the data processing agreement we could measure 7,941 companies; for security.txt 7,690. A share against all 8,449 would turn our own outages into vendor behaviour.

Who decides the weights?

We do, and that is why they are published: the methodology page reads them from the same file the score uses, and the table above repeats them. The score is frozen as version v1, so a new criterion never changes a number that is already published.

Can I quote these numbers?

Yes, with the date and the snapshot identifier. The data is published under CC BY 4.0, and the API and the bulk download carry the same kind of identifier as this piece.

Which vendor is best?

We do not say. The score is a public transparency score, not a product or security rating: it says how much a vendor published where we could read it, and nothing about whether the product is any good. Placement in a ranking is not for sale.

Method, snapshot and sources

Every figure above was read on 2026-09-13 from pages that render the live database, and each carried the snapshot r72.102956 in its footer. These commands pull the same figures for the snapshot the site is serving when you run them:

# the snapshot identifier
curl -s https://saas-ranking.com/api/v1/criteria | grep -o '"snapshot":"[^"]*"'

# found of measured, then not reached, per criterion (Figures 2 and 3)
curl -s https://saas-ranking.com/ | grep -oE 'ms-name">[^<]+|, [0-9,]+ of [0-9,]+ companies' | sed 's/ms-name">//' | paste - -

# vendors per band and vendors without a score (Figure 5)
curl -s https://saas-ranking.com/ | grep -oE 'Distribution of [^"]+|[0-9,]+ more without a score'

# the CRM example, one line per set of conditions (Figure 6)
for q in 'category=crm' 'category=crm&criteria=dpa' 'category=crm&criteria=dpa&criteria=subprozessoren' 'category=crm&criteria=dpa&criteria=subprozessoren&data=hosting:european-economic-area'; do curl -s "https://saas-ranking.com/explore?$q" | grep -o 'data-zahl="matching">[0-9,]*'; done

Every vendor and source behind these figures is on the criteria pages and in the read-only API. How often a published finding is right is measured on the data quality page against 461 findings read by hand, for the two extractors that have such a set.