Sub-processor disclosure: what a security review asks

What a sub-processor disclosure is

When a business handles personal data on behalf of its customers, the vendors it passes that data to are sub-processors. Article 28 of the GDPR requires a processor to disclose them and to have a data processing agreement in place with the customer.

In practice it is a page listing each third party that touches customer data, what it does and where it is, plus a DPA a customer can sign. For B2B software it is a standard item on a security review, and not having one delays deals.

What squirrel checks

The rule is site-wide and looks in two places, in order. First a crawled page whose URL path matches one of the sub-processor path patterns. Then, if none matched, a link on any crawled page whose text or href reads as a sub-processor or DPA reference. The first hit wins in crawl order. It emits a single check named subprocessor-disclosure:

• Skipped when no pages were crawled. Message: No pages available for analysis.
• Skipped when no disclosure is found and the site shows no commercial offer. Message: No commercial offer found (pricing, plans, enterprise or trust page); sub-processor disclosure applies to data processors with customers.
• Pass when a disclosure is found. Message: Sub-processor / data-processing disclosure found, with the URL as the value.
• Warn when none is found on a site with a commercial offer. Message: No sub-processor / data-processing (DPA) disclosure found, with Publish a /subprocessors page + DPA (GDPR Art. 28) as the value.

Severity info, weight 3. The rule only runs when the audit classified the site as SaaS, a web app or corporate, and, when a business category is known, as software and technology, fintech, banking or IT services. A classification below medium confidence, or an audit with no site metadata, runs it anyway.

The site type alone does not make a site a processor with customers. A pre-launch product with a waitlist has nobody’s data to process yet, so the rule only warns when the crawl shows a commercial offer: a crawled page at /pricing, /plans, /enterprise or /trust, or a link to one, or a link reading Pricing, Plans, Enterprise, Contact sales, Talk to sales, Book a demo or Trust center. Without one the check is skipped.

How to fix it

Publish a /subprocessors page listing each third party that processes customer personal data, what it is used for and where it operates. Link a DPA from your legal or trust pages, and keep the list current when you change vendors.

A stale list is worse than none in a security review, because it is checkable and the reviewer will check it.

Enable / disable

Disable this rule

[rules]
disable = ["legal/subprocessor-disclosure"]

Disable all Legal Compliance rules

[rules]
disable = ["legal/*"]

Enable only this rule

[rules]
enable = ["legal/subprocessor-disclosure"]

enable replaces the default ["*"], so this is the only rule selected. Leave disable out: a rule that matches any disable pattern is skipped even when enable names it. Only an enabled setting under a rule’s own [rule_options] table overrides both lists.

Related rules

• legal/privacy-policy: the policy that names the same vendors.
• legal/terms-of-service: the contract the DPA attaches to.
• security/third-party-cookies: the vendors visible from the page itself.
• eeat/trust-signals: the other things a buyer checks during review.

Legal Compliance findings ship in every audit next to the SEO, performance and agent experience rules. See Website security scan with AI for how an agent works through a report.

Glossary: Privacy policy.

References

• Third-party cookies, MDN

Check your site

Run squirrel audit https://example.com and open the Legal Compliance section of the report. The site is reported with the disclosure URL it found, or that it found none. Signed-out local audits need no account and cost nothing. Signed-in audits spend credits.