Compliance

Privacy by design in a B2B data company

20 May 2026 · 7 min read

“Privacy by design” is one of the most-used and least-understood phrases in compliance vocabulary. Companies put it on their websites. Auditors check whether the words appear in policies. Procurement teams scan for it in vendor questionnaires. The actual practice that the phrase is supposed to refer to — the engineering work, the architectural choices, the operational discipline — is often missing.

For a B2B data company, the phrase has a specific meaning that is worth being honest about. Privacy by design is not a policy. It is not a section in your terms. It is not a statement that you take privacy seriously. It is a set of structural choices that show up in the product itself, in the data model, in the engineering practices, and in how the company handles the requests it gets from regulators and individuals. If those choices are not there, no amount of policy language will make up the gap.

This piece is about what privacy by design actually looks like when you are running a B2B data company. We're describing what we do, not because it's exotic, but because we think it is going to become the baseline.

Choice 1: Minimize what you collect

The first and most consequential privacy-by-design choice happens before any data enters the system. It is the choice of what to collect in the first place.

A B2B data company that is honest about minimization collects what is needed for the use case — business identification and professional contactability — and not more. It does not collect personal phone numbers, personal email addresses, home addresses, or other categories that have nothing to do with the buyer's legitimate use case. It does not ingest data from breach dumps, social platforms that prohibit it, or sources whose chain of custody is unclear.

This sounds obvious. It is not what most of the industry does. The temptation to expand the dataset — more fields, more sources, more “enrichment” — is constant, because more data usually correlates with more revenue. A company that resists this temptation deliberately is making a privacy-by-design choice, even if it never uses the phrase.

Choice 2: Source provenance is a first-class field

Privacy by design means that every record carries its source as a structural feature, not as an afterthought. The provenance is not an audit log somewhere; it is a field on the record. It is queryable. It is exposed to the customer. It can be produced on demand for a regulator or a data subject.

This has a privacy effect that is bigger than it sounds. When provenance is first-class, the entire system becomes accountable in a way that vague systems are not. You cannot quietly ingest data from a dubious source if every record has to carry where it came from. You cannot launder data through a re-import if the original provenance is preserved across refreshes. You cannot tell a data subject that you don't know how you got their data, because the answer is on the record.

The discipline this imposes on the rest of the operation is the actual privacy mechanism. The provenance field is just where the discipline is visible.

Choice 3: Permanent suppression infrastructure

When an individual asks to be removed from a B2B database, two things must happen. The first is that their record is deleted. The second — and this is the harder one — is that they stay deleted.

A B2B data company that refreshes from upstream sources will, by default, re-ingest the same person from the same source the next time it runs. The deletion is undone by the next data pipeline run. The individual receives the same outreach they asked to stop, and has to start the process over again. This is not a hypothetical pattern; it is the modal experience that people report when they try to opt out of B2B databases.

Privacy by design requires building this problem out of the system. The technical mechanism is some form of permanent suppression list — a minimal set of identifiers that allows the system to recognize a previously-removed person if they appear again in a future refresh, and decline to re-ingest them. The suppression list itself is sensitive data; it has to be minimized, secured, and operated carefully. But it is the only way to make “removed” actually mean removed.

A vendor without a suppression list is, structurally, incapable of honouring a removal request in any durable way. They can mark the record as deleted today; they cannot prevent it from coming back next month. They are doing paperwork compliance, not real compliance.

Choice 4: Controller status, taken seriously

We've written separately about the controller question. The short version is: under GDPR Article 4(7), the entity that compiled a database and decides how it is organized is the controller for that database. There is no legitimate way around this, regardless of what marketing language a vendor uses.

Privacy by design means accepting controller status as the structural reality and operating accordingly. The privacy policy says so plainly. The DPA with customers reflects it. The subject access request workflow is built to handle real requests, not to deflect them. The supervisory authority is identified and registered with. The DPO — or the equivalent function — has the authority to actually pause processing if something goes wrong.

None of this is heroic. It is what the law expects. A surprising number of vendors structure themselves to avoid it. Privacy by design is, in part, the discipline of not doing that.

Choice 5: Subject rights as a real product surface

Article 15 of the GDPR gives data subjects the right of access. Article 16 gives them the right to correction. Article 17 gives them the right to erasure. Article 21 gives them the right to object to processing. These are not optional.

In practice, the difference between a privacy-by-design company and a compliance-theatre company shows up in how they handle these requests. A theatre company has a webform that goes to a shared inbox monitored erratically. A privacy-by-design company has a real workflow: identity verification, a timeline that meets the regulatory deadline, a recordkeeping system, a confirmation back to the requester, and a feedback loop into the system to make sure the request was actually applied to all records.

The cost of doing this properly is not trivial. It is a real operations function. Most B2B data vendors have under-invested in it for years, because most of their subjects don't know they have rights, and most who do know don't follow through. This works until it doesn't. As awareness rises — and it is rising — the vendors who treated subject rights as a side project are going to find themselves with operational debt that takes years to pay back.

Choice 6: Honest disproportionate-effort posture

Article 14 of the GDPR requires that data subjects be informed when their personal data is processed without having been obtained directly from them. There is an exception in 14(5)(b) for when notification would involve disproportionate effort. B2B data companies that collect from public sources at scale rely on this exception.

Privacy by design means relying on it honestly. The exception is not a blanket waiver. It requires the company to put in place safeguards that compensate for the absence of individual notification — a public, easily-findable privacy policy that describes the processing, a clear and accessible removal mechanism, and a serious posture on subject rights. A company that invokes the disproportionate-effort exception while making it hard to find the policy, hard to submit a removal request, or impossible to actually be removed is not relying on the exception; it is exploiting a regulatory loophole, and the loophole is closing.

The vendors who will be in good standing five years from now are the ones treating the disproportionate-effort exception as a duty to invest in the compensating controls, not as a license to skip them.

What this adds up to

Privacy by design in a B2B data company is six choices — minimization, first-class provenance, permanent suppression, accepted controller status, real subject-rights workflow, honest disproportionate-effort posture — all working together. Each one is a discipline. None of them is exotic. They are simply more expensive than the alternative.

What we have noticed is that companies that have made these choices have a different conversation with regulators, prospects, and individuals than companies that have not. The conversations are calmer. The questions get clean answers. The requests get processed. Nothing dramatic. The drama all sits on the other side, with the vendors who built their products on the assumption that nobody would look closely.

People are starting to look closely.

Privacy infrastructure, built in

See how Fullinfo handles privacy in practice.

Our privacy policy sets it all out plainly. Request early access and we'll show you what it looks like in the product.

Request Early Access →
Privacy by design GDPR Compliance Privacy engineering