GDPR Compliance When Using Dutch Business Registry Data

When you start using Dutch business registry data (KVK data) in your application, a natural question arises: what are the GDPR implications? Do you need consent? Can you store the data? What about sole proprietors whose home address is in the register?

This article provides a practical guide to navigating GDPR when working with Dutch company data. It is not legal advice — always consult a qualified attorney for your specific situation — but it will help you understand the key considerations.

Public Data vs. Personal Data

The first thing to understand is that KVK data occupies a unique position under GDPR. The Dutch Handelsregister (Commercial Register) is a public register. Its purpose is to provide transparency about businesses operating in the Netherlands. Most of the data it contains is intentionally public.

However, “public” does not mean “free from GDPR obligations.” The GDPR applies to all processing of personal data, regardless of whether that data is publicly available. The key question is: does the data you are using qualify as personal data?

What is not personal data

Data about legal entities (BV, NV, stichting, vereniging) is generally not personal data under GDPR:

• Company name of a BV or NV
• Registered address of a business premises
• KVK number
• SBI codes (industry classification)
• Date of registration
• Legal form

These relate to a legal entity, not a natural person.

What is personal data

Some KVK data does relate to identifiable natural persons:

• Sole proprietor (eenmanszaak) details: the name of the owner is personal data
• Home addresses: when a sole proprietor operates from home, their registered address is a home address
• Names of directors and authorized representatives: these identify natural persons
• BSN numbers: though these are not available via public APIs, they exist in the full register

The Sole Proprietor Challenge

Sole proprietorships (eenmanszaken) are the most sensitive category. In the Netherlands, there are hundreds of thousands of registered sole proprietorships. For these businesses:

• The trade name often includes the owner’s personal name
• The registered address may be a residential address
• The KVK number is directly linked to an individual

The KVK itself has recognized this issue. Since 2022, sole proprietors can request that their home address be shielded from public view. However, not all have done so, and older data may still contain these addresses.

How to handle this

When your application processes data about sole proprietorships, consider these steps:

1. Do not store more than you need: if you only need the company name and KVK number, do not store the address
2. Distinguish between business and home addresses: if possible, flag when an address might be residential
3. Provide a way for individuals to request removal: sole proprietors should be able to ask you to delete their data
4. Document your legal basis: explain why you need this data (see below)

Legal Basis for Processing

Under GDPR, you need a legal basis for processing personal data. For business registry data, the most common bases are:

Legitimate interest (Article 6(1)(f))

This is the most frequently used basis for processing public business registry data. You have a legitimate interest in knowing who you are doing business with and conducting due diligence. To rely on it, identify your interest, demonstrate necessity, balance against data subject rights, and document the assessment.

Contract performance (Article 6(1)(b))

If you are processing KVK data to fulfill a contract — for example, generating an invoice with the correct legal name and address — then contract performance is your legal basis.

Legal obligation (Article 6(1)(c))

Some processing of business data is legally required. For example, Dutch tax law requires you to verify BTW numbers for intra-community transactions.

Data Minimization

GDPR requires you to collect and process only the data you actually need. Apply this principle to your KVK data integration:

• If you only need to verify that a company exists, do not store the full profile
• If you need the company name for invoicing, you do not necessarily need the SBI codes
• If you are doing a one-time validation, consider not storing the data at all

// Example: store only what you need
function extractRelevantFields(kvkResponse) {
  return {
    kvkNumber: kvkResponse.kvkNumber,
    tradeName: kvkResponse.tradeName,
    // Only store address if needed for invoicing
    invoiceAddress: needsInvoicing
      ? formatAddress(kvkResponse.address)
      : null,
    // Do not store owner name if you do not need it
    verifiedAt: new Date().toISOString()
  };
}

Storage Limitations

GDPR requires that you do not keep personal data longer than necessary. Define clear retention periods:

• Active customer data: retain for the duration of the business relationship
• Invoice data: Dutch law requires 7-year retention for tax purposes
• Lookup cache: short-lived (24 hours to 7 days), then refresh from source
• Prospect data: define a reasonable period (e.g., 12 months of inactivity)

// Example: automatic cleanup of cached data
async function cleanupOldCacheEntries() {
  const cutoffDate = new Date();
  cutoffDate.setDate(cutoffDate.getDate() - 7);

  await cache.deleteWhere('createdAt < ?', cutoffDate);
}

Practical Compliance Checklist

Use this checklist when integrating KVK data into your application:

• Identify which KVK fields you actually need and determine your legal basis
• Document your legitimate interest assessment (if applicable)
• Update your privacy policy to mention KVK data processing
• Apply data minimization — only request and store necessary fields
• Handle sole proprietor data with extra care
• Implement data retention and cleanup policies
• Support data subject rights: access (Art. 15), deletion (Art. 17), objection (Art. 21), and portability (Art. 20)
• Review and refresh cached data periodically

Working with a Data Processor

If you use a third-party API like KVKBase to access KVK data, you need to consider whether that provider is a data processor under GDPR. In most cases, an API provider that retrieves and returns data on your instruction qualifies as a processor, and you should have a Data Processing Agreement (DPA) in place.

Conclusion

Using Dutch business registry data is generally straightforward from a GDPR perspective, especially when dealing with data about legal entities like BVs and NVs. The main area requiring extra attention is sole proprietor data, where personal information is intertwined with business data.

By applying data minimization, defining clear retention policies, and documenting your legal basis, you can use KVK data confidently and compliantly. When in doubt about your specific situation, consult with a privacy professional.