Data Processing Agreement

What happens on your site. Company identification determines the company likely behind an anonymous business visit. It is a company-level operation that involves no device access, no cookie and no identifier read from the visitor’s device; it uses the IP address the request arrives from. It is on by default on paid plans and you can turn it off in Settings. On paid plans we store the full IP addresson the visitor’s enrichment record until our enrichment job resolves the company — the job runs every three hours — and then delete it, unless you turn on “Store visitor IP”, in which case we keep it until you delete it or the workspace is deleted. IP addresses are never written to analytics events. If your snippet uses a consent mode, none of this runs until the visitor grants consent. We perform this processing as your processor; as controller you rely on your legitimate interest (GDPR Art. 6(1)(f)) in B2B account identification, or on consent where you choose to collect it.

What we keep for our own graph. On every plan, including Free, and unless company identification is turned off, we record the visitor’s network prefix— truncated to a /24 for IPv4 or a /48 for IPv6 before it is written — with the pseudonymous visitor id, country, time zone and connection type (at most 8 networks per visitor, deleted 30 days after the visitor was last seen on that network). Where a paid workspace has turned on “Store visitor IP”, the full address is recorded here instead, for the same 30 days, but the graph only ever reads it as a prefix. We use these observations to maintain our own IP-to-company graph, which maps networks to the organisations that use them and powers identification for all customers. For that purpose we act as an independent controller, not as your processor, on the basis of our own legitimate interest (Art. 6(1)(f)) in accurate company-level identification. We have weighed it against visitors’ interests: prefixes and company domains only, no device access, never used to identify, profile or contact an individual, and a 30-day expiry. Our Privacy Policy gives visitors the information Art. 14 requires and an objection route.

Confirmation signals. Three sensors feed the graph, each recording a network prefix (/24 for IPv4, /48 for IPv6) paired with a company email domain(never the local part) and your site’s pseudonymous visitor or contact id: (1) a form submission or verified signup with a corporate email; (2) a click on a link in an outreach email your workspace sent, captured on our redirect; (3) the originating mail-server IP in the Received / X-Originating-IP headers of a reply to that outreach. Before a click or reply is counted we exclude link scanners and mail-security gateways (fetches within seconds of delivery, fan-out across many links, known wrapper hosts, automated user agents) and any address our own graph classes as hosting, VPN or relay. Confirmations that are not corroborated expire after 30 days; a corroborated one becomes a company-level network-to-organisation entry holding nothing about the visitor. These signals only ever confirm a company; they are never used to identify a person.

Coverage benchmark.A daily sample of resolved addresses and network prefixes is scored against the ipapi.is sub-processor to measure the graph’s accuracy, with no visitor id or workspace attached, and deleted after 30 days.

Where it is stored. These records are held in our main database, which is hosted in the United States (see International transfers).

Opting out.Turn company identification off in Settings → Visitor enrichment, which stops both the reveal and your site’s contribution to the graph; on any plan you can also ask us to stop your site contributing by writing to privacy@businessmcp.com.

Person-level identification (resolving a named individual) is a separate, stricter feature that is device-based, US-only under notice-and-opt-out, off in the EU/UK absent consent, and disabled whenever a Global Privacy Control signal is present — see our Privacy Policy.

You authorise the sub-processors in the register at businessmcp.com/privacy#sub-processors. The register states each vendor’s purpose, the data it sees, its location and whether it only processes data when you connect or enable it. We impose data-protection terms on each that are no less protective than this DPA and remain liable for their performance.

Notice and objection. We email workspace owners at least 30 daysbefore a new sub-processor starts processing data for every workspace, and update the register’s Last updated date. You may object within that period on reasonable data-protection grounds by writing to privacy@businessmcp.com. If we cannot offer a workable alternative, you may terminate the affected service without penalty. Vendors marked only if you connect it are engaged by your own configuration and need no notice.

Our main database and application hosting are in the United States, and our raw analytics event store is in London, United Kingdom; each sub-processor’s location is in the register. Personal data from the EEA/UK is therefore transferred outside it. For those transfers the parties rely on the European Commission’s Standard Contractual Clauses (and the UK International Data Transfer Addendum for UK data), which are incorporated into this DPA by reference, and we require equivalent safeguards from our sub-processors. Transfers of EEA data to the United Kingdom rely on the European Commission’s adequacy decision for the UK.