Subprocessors and Service Providers

Last revised: 8 September 2026. Status: provider disclosure under review. Legal review: not yet recorded. This version has no effective date.

No named production subprocessor is confirmed by this public register yet. This means the register is incomplete; it does not mean the service uses no external companies.

Before relying on a processing location or approving the service for production data, request the current provider record through [[email protected]](mailto:[email protected]). The operator must verify provider legal names, actual use, contracts, and locations before publishing named entries.

A subprocessor is a provider that processes Customer Personal Data for DataVisitors while DataVisitors acts on the customer's instructions. The provider's actual function determines whether it belongs in that register.

Not every integration is a subprocessor. A customer-selected webhook destination or connected application can belong to the customer's own provider chain. A company can also act as a separate controller for a distinct activity, such as parts of payment processing.

These functions can host the application, store customer analytics and account records, or maintain recovery copies. Their scope can include personal data held in the relevant service databases and permitted support access.

The completed record must name the contracted provider, primary processing country, backup locations, remote-access locations, and relevant transfer safeguards. A server address or a deployment script is not a substitute for that record.

A network provider can deliver requests, terminate encrypted connections, filter abusive traffic, or operate related infrastructure. Depending on the configuration, it can process network addresses, request metadata, and information carried through the connection.

The operator must distinguish authoritative DNS alone from proxying application traffic. Those activities expose different information. The final entry must describe the actual configuration and any relevant regional controls.

Email delivery can process recipient addresses, message content, and delivery status. Messages can include verification links, password resets, optional reports, support replies, or configured alerts.

A browser notification can use the push service associated with the subscriber's browser. The operator must assess the role of that service and disclose the relevant processing. Customer-configured webhook destinations require a separate customer assessment.

The final email entry must identify the active transport provider. A local development outbox does not establish who delivers production mail.

Where payments are enabled, a payment service can process checkout, payment, billing, fraud-prevention, and transaction information. Its role can vary by activity. The completed disclosure must identify the provider and link the relevant data-protection terms.

Any optional explanation or external processing service needs an assessment before customer information is sent to it. Available code or a supported adapter does not prove that such a service is enabled.

A locally installed geographic database does not receive visitor data merely because the application reads it. The operator must assess update downloads or other network activity separately from local lookups.

Every confirmed entry must state:

• The provider's legal name and the service used.
• Whether it acts as subprocessor, separate controller, or another relevant recipient.
• The purpose and the categories of data it receives.
• The relevant processing and support-access locations.
• The applicable transfer mechanism where one is required.
• The contractual or privacy information needed for customer assessment.
• The authorization status and the date the provider begins relevant processing.

A brand name without a service description or processing location is not a complete entry.

The completed Data Processing Agreement must define prior authorization and the method for notifying customers of intended additions or replacements.

For general authorization, the customer must receive advance notice and a reasonable opportunity to raise a data protection objection. The completed agreement must state the notice channel and objection period. This page does not invent a subscription mechanism or a notification deadline that the service has not established.

A provider change must follow that process before the new relevant processing begins. Material changes to function, location, or safeguards also require review.

If you export data, send an alert to a webhook, or authorize another application, review the receiving system's terms and privacy practices. Limit the information you send and revoke access when it is no longer needed.

Those choices can create recipients outside DataVisitors's own subprocessor chain. Revoking future access does not remove copies the recipient already obtained.

For provider questions, use Contact. Read the Privacy Policy, Cookie Policy, and Data Processing Agreement for the related responsibilities.