Netherlands software delivery: GDPR enforcement, accessibility, Peppol and Dutch payments

OutsourcingVN is operated by Netbase JSC, so this guide is written by a supplier that would like your project. It sets out what Netbase can evidence for a Dutch brief, points to the official references your own advisers should read in full, and names the decisions that stay with you. The guides index lists guides for other markets, and the market index compares the first question each one raises.

Contents

• Who enforces data protection for a Dutch-facing product?
• What can Netbase evidence for a Dutch brief?
• Which requirement sits with which decision owner?
• Which steps come before a Dutch-facing launch?
• Worked scenario: a Dutch customer asks for their data
• What has Netbase built for Dutch clients?
• Which questions should you ask a supplier?
• What usually goes wrong?
• How this guide is sourced and where it stops
• Common questions
• Plan the first release

Who enforces data protection for a Dutch-facing product?

GDPR applies across the European Union, and the Netherlands reaches it through its own national supervisory authority rather than a separate Dutch law layered on top. A controller must have a lawful basis for each use of personal data, honour access, correction, erasure and portability requests, and tell its supervisory authority of a qualifying breach within 72 hours of becoming aware of it. Fines can reach the higher of €20 million or 4% of global annual turnover.

None of that changes because the development team sits outside the Netherlands. What changes is who signs the processing agreement, who is named as controller or processor, and who answers the supervisory authority's questions if a Dutch user complains. A buyer should decide those three roles before discovery starts, not after a defect is found.

What can Netbase evidence for a Dutch brief?

Procurement, security and data protection reviewers tend to ask for the same four statements. These are the ones Netbase can give.

• Compliance practices. Netbase's compliance practices are GDPR alignment for data privacy in Europe, HIPAA-aligned methodologies for healthcare data handling, and CCPA compliance for clients with U.S. customer bases. Deciding how GDPR applies to your own product and who your Dutch data protection officer is remains your organisation's task.
• Security practices. Security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request. A data processing agreement for a Dutch-facing system sits on top of this baseline.
• Information security management. Netbase JSC holds ISO 27001 certification for information security management. The certification belongs to Netbase as a company; it is not extended to a product built for a client or to its hosting.
• Markets and language. Netbase clients are in the United States, Europe and Asia-Pacific, and most projects come from clients outside Vietnam. Delivery communication is in English, so a Dutch-facing product's own localisation into Dutch is scoped as a project task, with a named Dutch copy owner.

Which requirement sits with which decision owner?

A Dutch brief usually spans four separate owners inside the buying organisation. Splitting the requirement from the evidence from the decision keeps a proposal from promising more than one team can check.

Ask for this table filled in, not just a general compliance statement, before shortlisting a supplier.

Worked scenario: a Dutch customer asks for their data

A Dutch customer emails asking what personal data a loyalty programme holds about them and for a copy in a portable format.

A proposal that cannot describe step 3, specifically how the export keeps one customer's data separate from another's, has not yet scoped data portability for this product.

What has Netbase built for Dutch clients?

The nearest published evidence for a Dutch brief is commerce work: Netbase has built a web-to-print store with an online design tool for an interior and furnishing panels business in the Netherlands, and a Magento store with companion Android and iOS apps for a women's fashion retailer in the Netherlands, for clients that are not named. The web-to-print stores record covers the design-tool scope across four countries including the Netherlands; the Dutch fashion retailer's app work sits outside that record's print-commerce scope.

Which questions should you ask a supplier?

• Who signs the data processing agreement, and who is named controller? Expect a clear answer before contract, not during a breach.
• What exactly does your security and compliance statement cover? A precise answer says what it does not cover as well as what it does.
• Can you show a Peppol invoice export from a past project? Ask for the structure, not just a claim that it exists.
• Who owns the Dutch copy, and how does a change reach production? Translation drift is easiest to catch before launch, not after.
• How is iDEAL integrated, and who holds the merchant relationship? The payment provider relationship usually stays with the buyer.
• Who decides if an accessibility defect blocks release? It should be your product or service owner, not the supplier.

What usually goes wrong?

• A company-level compliance statement read as project proof. Signal: nobody has tested this product's own data flows or access controls. Owner: the data protection lead.
• Accessibility treated as a launch-week task. Signal: a long defect list appears days before release. Owner: the product owner, testing each journey during the build.
• iDEAL added after checkout is already built around cards. Signal: a late, disruptive change to the payment flow. Owner: the product owner, scoping payment methods at discovery.
• Dutch copy translated once and never re-tested. Signal: error messages and generated documents drift out of Dutch after the first release. Owner: the localisation owner.

How this guide is sourced and where it stops

This guide draws on the European Commission's Your Europe business pages on GDPR and e-invoicing, the Peppol network's own description of itself, the Dutch government's digital accessibility site, and iDEAL's own description of its payment scheme, all checked on 2026-10-03, together with company statements and a delivery record approved in the OutsourcingVN claim register. It is written for product, procurement and operations leads scoping a Dutch-facing brief. It does not decide which accessibility standard or data protection role fits your organisation; your own advisers make that call.

Plan the first release

Bring your data protection role split, your accessibility standard, your Peppol and payment decisions, and your Dutch-language scope. The data security and compliance guide lists the contract questions behind the data protection row, and the time zone and collaboration guide covers how overlap and handoff are agreed for a European working day. For neighbouring markets, the UK guide covers UK-specific accessibility duties and the Germany guide covers works-council consultation and German e-invoicing formats; the France guide covers CNIL guidance and the French e-invoicing reform.

Custom Product Engineering is the service for a bounded build, and global delivery explains how remote delivery is organised. OutsourcingVN is Netbase's own outsourcing-services platform: submit a project with your Dutch-facing scope, and a person will reply with whether discovery or a bounded implementation is the right next step.

Related services and solutions