Modernising Dutch Municipal IT

Architecture, Standards & the Road to Common Ground

A practical guide to the GEMMA reference architecture, Common Ground, the key standards every gemeente must implement, and the design principles that should govern every new integration project.

The Netherlands has around 342 municipalities. Each one must deliver a growing portfolio of digital citizen services — permit applications, benefit processing, public space management, civil registration — while navigating a complex landscape of legacy IT, mandatory open standards, evolving national architectures, and increasing pressure to reduce both cost and vendor dependency.

Over the past few years, the VNG (Vereniging van Nederlandse Gemeenten) has been working on a fundamental shift in how gemeente IT should be designed. That shift goes by the name Common Ground, and it is underpinned by the renewed GEMMA reference architecture. Understanding both — and the standards they require — is essential for any integration architect, project lead, or IT manager working with or for Dutch municipalities.

This post is a structured introduction to the landscape: what the frameworks are, how they relate to each other, what the key standards require, and what design principles should govern every new gemeente integration project.

The Dutch Municipal IT Landscape Today

Most Dutch gemeenten operate IT landscapes that have accumulated over 20–30 years. The typical picture looks something like this:

A large, often monolithic zaaksysteem (case management system) from one of a handful of dominant vendors
20 to 40 connected taakapplicaties (specialist applications for specific tasks) — each with its own database, its own data model, its own copies of citizen data
Data integration based primarily on StUF (Standaard Uitwisselingsformaat), a SOAP/XML-based messaging standard that has been the backbone of gemeente data exchange since the early 2000s
Local copies of national base registrations (BRP, BAG, BRK) — each gemeente maintaining its own synchronised local extract of citizen, address, and property data

The current architecture creates what VNG calls a “lappendeken” (patchwork quilt): systems are built in silos, data is replicated everywhere, no one source is authoritative, and every new integration creates more fragility. The result is high cost, slow delivery, and a digital infrastructure that cannot keep pace with citizen expectations or legislative change.

Three developments are converging to make the status quo untenable. First, the volume and complexity of digital service delivery is increasing — driven in part by the Omgevingswet, the digitalisation of benefits, and citizen expectations shaped by commercial digital services. Second, VNG has formally frozen StUF development — the standard will receive no new features, only legislative corrections. Third, a new cohort of open-source, API-first applications is emerging that makes the old silo architecture unnecessary.

The Architecture Framework Hierarchy

Any integration work for a Dutch gemeente needs to situate itself within a hierarchy of reference architectures. Working from European to local level:

EIRA

European Interoperability Reference Architecture: EU-level framework for interoperability across member states. The top-level parent of the Dutch hierarchy.

NORA

Nederlandse Overheid Referentie Architectuur: National interoperability framework for all Dutch government organisations. Translates EU principles into Dutch policy and architecture guidance.

GEMMA

Gemeentelijke Model Architectuur: Municipal reference architecture — the governing anchor for all gemeente IT decisions. A daughter architecture of NORA; compliance with GEMMA implies compliance with NORA and EIRA. Renewed 2024/2025.

Common Ground

Common Ground Vision & Implementation Direction: VNG programme that defines how GEMMA should be realised in practice: data at source, API-first, component-based, open standards. Not a separate architecture — the implementation direction of GEMMA.

A critical nuance: Common Ground is not a parallel framework to GEMMA. VNG archived the older Common Ground information architecture principles page in 2024/2025 precisely because the renewed GEMMA principles now form one coherent set aligned with Common Ground. When someone says “this solution must align with Common Ground,” they mean it must align with the renewed GEMMA principles — which already incorporate the Common Ground vision.

Official Sources

GEMMA: The Governing Reference Architecture

GEMMA — Gemeentelijke Model Architectuur — is the national reference architecture maintained by VNG for all Dutch municipalities. Its 2024/2025 renewal is significant: it now encompasses business architecture, information architecture, and (since 2024) technical architecture, giving it coverage from process design all the way down to deployment infrastructure.

What GEMMA Provides

Architecture principles — binding direction for how municipality information systems should be designed
Process architecture — a reference model for municipal business processes (the GEMMA procesarchitectuur, available in tools like Sensus BPM)
Information architecture — how information should flow, where data lives, and how systems relate
Technical architecture — added in 2024; describes technology services, components, and cloud deployment models in ArchiMate
Domain architectures — specific architectural guidance for domains including Sociaal, Fysieke Leefomgeving, Publieksdiensten, and Bestuur
Standards list — the GEMMA standaardenlijst defines which standards are recommended or mandatory per reference component

GEMMA’s Scope
GEMMA is a generieke (broadly applicable) architecture — it describes what any gemeente should do, not every detail of how one specific gemeente should do it. A gemeente architect uses GEMMA as the starting point and translates it into a local enterprise architecture suited to that organisation’s specific situation.

The Service Orientation Principle

The leading architecture style in GEMMA — in line with NORA and EIRA — is service orientation: thinking in terms of loosely coupled, reusable services. The core objective is hoge samenhang binnen, losse koppeling tussen (high cohesion within, loose coupling between) components. This is the direct precursor to what Common Ground calls its component-based architecture: each function is a service that can be built, deployed, and replaced independently.

Official Sources

Common Ground: The Implementation Direction

Common Ground emerged from a question that a group of large municipalities — the G5 (Amsterdam, Rotterdam, Den Haag, Utrecht, Eindhoven) — and VNG started asking around 2017: what if we built municipality IT from scratch today? What would change?

The answer was a set of principles that together constitute what VNG now calls the informationkundige visie (information-architectural vision):

Data bij de bron — Data stays at its authoritative source; applications query it when needed rather than maintaining local copies
Scheiding van lagen — Contact, service, process, integration, and data are strictly separated as distinct layers
Componenten in plaats van silo’s — Applications are composed of loosely coupled components rather than monolithic integrated suites
Open standaarden — APIs use REST/JSON with published OpenAPI specifications; events use standardised formats
Open source waar mogelijk — Where open source is available and secure, it is preferred over proprietary solutions
Samen organiseren — Municipalities develop, share, and reuse components collectively rather than each building their own solutions

The Practical Implication
In the Common Ground model, a gemeente portal does not need its own copy of citizen data. When a citizen submits a vergunning application, the portal calls the national BRP (Basisregistratie Personen) directly via the Haal Centraal API to verify their identity and address. The data lives once, at its authoritative source, and is queried at runtime. This eliminates an entire class of integration problems.

Common Ground also introduced the concept of the Groeipact — a commitment signed by municipalities, VNG, and major vendors to work together toward the Common Ground vision. It is not a technical specification but a governance commitment, and it shapes how procurements and supplier relationships are framed.

Official Sources

The Common Ground Five-Layer Architecture

Common Ground describes a five-layer architecture model. It is not a deployment model — it is a separation of concerns model. Every component in a gemeente’s information landscape should be mappable to exactly one of these layers:

Layer 1: Contact

Citizen and business-facing channels — the MijnGemeente portal, mobile apps, OpenForms digital forms, third-party portals, and the KCC (Klant Contact Centrum). This layer handles presentation and interaction. It must be decoupled from business logic; the same service must be accessible from any channel.

Layer 2: Service

Business services and domain logic — the applications that implement specific municipal tasks: vergunning processing, uitkering assessment, melding handling, civil registration. These are the “apps” in the Common Ground appstore metaphor.

Layer 3: Process

Orchestration and workflow — the handling of cases (zaken) across their lifecycle: intake, assessment, decision, notification, archiving. This is where Zaakgericht Werken (ZGW) lives. Process logic should be explicit, auditable, and independent of any specific application.

Layer 4: Integration

API gateway and adapters — the translation, routing, and security enforcement layer between components and between organisations. API management, protocol translation, FSC/NLX connectivity, and event distribution all live here. This is the layer where legacy StUF systems are bridged to modern ZGW APIs.

Layer 5: Data

Source registrations and data stores — the authoritative data sources: national base registrations (BRP, BAG, BRK, HR) accessed via Haal Centraal APIs, and municipality-specific registers for zaak records, documents, and decisions. Data in Layer 5 is never replicated to upper layers without explicit justification.

A component that crosses two layers is a design smell. An integration that reaches from Layer 1 directly to Layer 5, bypassing process and integration layers, is a violation. This model is what makes it possible to replace individual components — a new DMS does not require rebuilding the citizen portal, because they are in different layers communicating only through defined interfaces.

The 12 Design Principles

The following principles derive from the renewed GEMMA architecture principles (2024/2025), NORA, and Dutch government standards. Any new gemeente integration solution — whether built by the gemeente itself, a systems integrator, or a software vendor — should be evaluated against these twelve principles.

P1 : Data bij de Bron

Query authoritative source registrations at runtime. No local copies of base registration data unless legally required and explicitly justified.

P2: Scheiding van Lagen

Maintain the five-layer model as distinct deployment and responsibility boundaries. No cross-layer direct calls; communicate through defined interfaces.

P3: Standaard Interfaces

REST adapters expose OpenAPI 3.0 specifications conforming to NLGov REST API Design Rules. SOAP-based transitional StUF adapters expose WSDL/XSD plus canonical mapping documentation. All events conform to NL GOV CloudEvents v1.1 (mandatory since OBDO 25 November 2025).

P4: Leverancieronafhankelijkheid

Integration logic is expressed in portable formats in version-controlled infrastructure-as-code. No business logic lives in proprietary service configuration that cannot be exported or reproduced on another platform.

P5: Losse Koppeling

Systems communicate via the integration layer only — never direct system-to-system. Async communication via standardised events is preferred over synchronous calls wherever latency permits.

P6: Zaakgericht Werken

All citizen service processes produce a ZGW zaak as the authoritative process record. Documents via ZGW DRC. Decisions via ZGW BRC. ZGW APIs are target state; StUF is transitional only.

P7: Veilige Identiteit

Citizen authentication via DigiD (assurance level matched to service sensitivity). Business authentication via eHerkenning. System-to-system via OAuth 2.0. No authentication logic in application code.

P8: Zero Trust API

No implicit trust between services. Every API call carries a JWT validated at the gateway boundary. Scopes enforced per operation. Policy-Based Access Control (PBAC) replaces simple role checks for sensitive data.

P9: Logboek Dataverwerkingen

Every access to personal data is logged per the Logboek Dataverwerkingen (LDV) standard — managed by Logius, in the PTOLU standardisation trajectory. BSN is never written to application logs.

P10: Privacy by Design

Data minimisation per processing purpose. In the sociaal domein: legal basis is statutory task or public task (AVG Art. 6(1)(c)/(e)) — consent is almost never valid due to the afhankelijkheidsrelatie between municipality and resident (per Autoriteit Persoonsgegevens).

P11: BIO 2.0 / NIS2-Aware

BIO 2.0 baseline controls apply. Municipalities are confirmed in scope of the Cyberbeveiligingswet (Dutch NIS2 implementation), targeting Q2 2026 entry into force. Platform design should be NIS2-aware now.

P12: OIN / Digikoppeling

OIN (Organisatie-identificatienummer) is used for certificate subjects, event source URNs, and Digikoppeling endpoint identification. Profile selection (WUS, ebMS2, REST) is a platform-level decision, not per-adapter.

Standards Every Gemeente Must Know

Forum Standaardisatie maintains the “Pas toe of leg uit” (PTOLU) list — the mandatory standards list for Dutch government organisations. Procurement law requires organisations to either apply these standards or explicitly explain why they have not. The table below covers the standards most relevant to gemeente integration work.

Table 1: BizTalk BRE Components vs. Azure Logic Apps Rules Engine Concepts

Standard	What It Governs	Status	Reference
NLGov REST API Design Rules v2.0	Structure and naming rules for all government REST APIs. Every published API must have an OpenAPI 3.0 spec.	PTOLU OBDO Nov 2025	Logius
NL GOV profile for CloudEvents v1.1	Mandatory envelope format for all government event/notification exchanges. Builds on the CNCF CloudEvents specification.	PTOLU v1.1 current	Logius
Digikoppeling	Government-to-government system integration. Profiles: WUS (SOAP/sync), ebMS2 (async/reliable), REST. Profile selection must be made per integration type.	PTOLU	Logius
ZGW API Standards (ZRC, DRC, ZTC, BRC)	REST/JSON APIs for case management (Zaakgericht Werken). Target state for case, document, case-type, and decision registration.	VNG Standard	VNG Realisatie
Haal Centraal APIs	Direct REST access to national base registrations: BRP (persons), BAG (addresses/buildings), BRK (cadastre), WOZ (property valuation).	VNG/RvIG/Kadaster	VNG Realisatie
FSC — Federatief Stelsel Communicatie	Secure, authenticated inter-organisation data exchange. Successor to NLX; VNG standard since 2025.	VNG Standard 2025	VNG
StUF (BG, ZKN, HR)	Legacy SOAP/XML messaging standard. Still mandatory for existing integrations (PTOLU “Comply or Explain”). Development frozen.	PTOLU — Frozen	VNG Standaarden
Logboek Dataverwerkingen (LDV)	Standard for logging data processing actions with purpose binding, legal basis, and actor. Managed by Logius. Replaces the defunct VNG Verwerkingenlogging API.	In PTOLU trajectory	Logius
NLGov OAuth 2.0 Assurance Profile	Dutch government profile on OAuth 2.0 for authorisation of API access. PTOLU mandatory.	PTOLU	Logius

Forum Standaardisatie — Official Lists

Identity & Authentication: DigiD and eHerkenning

Authentication is the most legally and technically constrained component of any citizen-facing gemeente system. The Dutch national identity infrastructure mandates specific authentication services depending on who is authenticating and the sensitivity of the service.

DigiD — Citizen Authentication

DigiD (Digitale Identiteit) is the mandatory authentication service for citizens, operated by Logius under RvIG (Rijksdienst voor Identiteitsgegevens). It uses SAML 3.x and provides three assurance levels:

DigiD Basis (Level 2) — username/password. Appropriate for standard services: permit applications, melding submission, civil status enquiries.
DigiD Substantieel (Level 3) — app-based authentication with device binding. Mandatory for services with financial impact: social benefits, health-related services, high-value permits.
DigiD Hoog (Level 4) — hardware token. Required for the most sensitive services; rarely encountered in municipal contexts.

DigiD is a Legal Gate, Not a Technical Feature
Before any production DigiD integration is possible, the gemeente must: (1) be listed on the Autorisatielijst BSN-gerechtigden (ALB) managed by RvIG, (2) have a signed connection agreement with Logius, and (3) have completed an annual ICT security assessment. The minimum connection process takes at least one month. The BSN (Burger Service Nummer) received from DigiD must be handled with extreme care — it must never appear in application logs or be stored beyond immediate processing requirements.

eHerkenning — Business Authentication

eHerkenning is the business-facing equivalent of DigiD, providing authentication and authorisation for companies and organisations. It is managed by Logius and delivered by a network of accredited Authenticatiediensten (commercial providers). Key assurance levels for gemeente contexts:

EH2+ — Standard business services: permit applications, environmental declarations, standard registrations
EH3 — Sensitive services involving financial impact or access to sensitive business data; increasingly common for omgevingswet-related services

eHerkenning also covers machtigen (delegation) — the ability for a business owner to delegate access to an employee or accountant. The Machtigingenregister (managed by Logius) validates these delegations at authentication time.

Official Sources

Processing Accountability: Logboek Dataverwerkingen

The AVG (GDPR) requires every organisation processing personal data to be able to demonstrate that processing meets its core principles: lawfulness, transparency, purpose limitation, data minimisation, accuracy, and storage limitation. For municipalities, which process enormous volumes of personal data across dozens of systems, this accountability obligation is a significant architectural challenge.

The VNG previously developed a Verwerkingenlogging API standard for this purpose. However, a 2023 legal review concluded that the standard as designed had no AVG legal basis for a central processing register, and VNG formally abandoned it. The replacement is the Logboek Dataverwerkingen (LDV) standard, now managed by Logius under BZK since summer 2024 and currently in the PTOLU standardisation trajectory.

LDV requires that for every data processing action involving personal data, the following metadata is recorded in an immutable log:

A unique processing ID (linked to the specific action)
A reference to the processing activity in the gemeente’s VAR (Verwerkingsactiviteitenregister, AVG Art. 30 register)
The system actor performing the processing
A timestamp
The data items accessed, and the legal basis for that access

Important Design Note
The VAR (Verwerkingsactiviteitenregister) must be populated with unique UUIDs for each processing activity before LDV logging can be implemented correctly for that scenario. This is the responsibility of the gemeente’s privacy officer or DPO — not the integration team. Making the VAR available via API (recommended by Logius) makes this machine-processable.

Official Sources

StUF: Mandatory, Frozen, and Transitional

No overview of Dutch municipality IT architecture is complete without addressing StUF directly. It is the most important thing to understand about the current state of the landscape — and the most misunderstood.

StUF (Standaard Uitwisselingsformaat) is a SOAP/XML messaging standard developed by VNG. It has been the backbone of municipality system integration for over 20 years. Key sector models include:

StUF BG — Basis Gegevens (person, address, building data)
StUF ZKN — Zaken (case management, predecessor to ZGW)
StUF HR — Handelsregister (business register data)

StUF’s Current Status: Three Facts in Tension
Fact 1: VNG has formally stopped all further development of StUF standards, sector models, and koppelvlakken. Only legislative changes or discovered errors can trigger a new version.
Fact 2: Forum Standaardisatie’s Steering Group recommended in February 2025 that StUF should remain on the PTOLU mandatory list — so it is still a compliance obligation for existing integrations.
Fact 3: VNG explicitly states that StUF is being replaced by API standards (ZGW, Haal Centraal) as the Common Ground realisation. StUF is transitional — correct architecture posture is to build new integrations using ZGW, and to bridge legacy StUF systems via adapters during migration.

The practical implication: if you are building a new integration for a gemeente today, you should not design new StUF-based integrations. You should design ZGW/REST integrations, and if a connected system only speaks StUF, you build an adapter that translates — ideally via XSLT transformation in an integration layer. The StUF adapter is a transitional bridge, not the target architecture.

VNG estimates that the full migration from StUF to ZGW across the gemeente landscape will take until at least 2028 for most municipalities. A bi-directional StUF-ZGW bridge is therefore not a workaround — it is a legitimate and necessary architectural component for any platform serving real gemeenten today.

Official Sources

What This Means in Practice

For any organisation working with or for Dutch municipalities on integration projects, the framework described above translates into a set of concrete architectural commitments:

Govern against GEMMA. Every design decision should be traceable to a GEMMA architecture principle. If a proposed solution violates a principle, that violation needs to be explicitly justified — not ignored.
Adopt the five-layer model as a deployment boundary, not just a diagram. Services in different layers should be independently deployable. Cross-layer direct communication is a design smell that accumulates technical debt.
Design ZGW-first, bridge StUF. New integrations use ZGW APIs. Legacy systems are accommodated via bi-directional adapters in the integration layer — adapters that translate protocols without storing business data.
Query at source; never copy. BRP, BAG, and BRK data is accessed via Haal Centraal APIs at runtime. Local base-data copies are a violation of the data-at-source principle unless legally mandated.
Implement LDV as a platform capability, not an afterthought. Every personal data access must emit an LDV-compliant log entry referencing a VAR activity UUID. This is not a feature to add at the end — it must be built into the integration flow from the start.
Plan DigiD early. The DigiD connection process has a minimum one-month lead time and legal prerequisites that must be initiated at the start of a project, not after architecture is complete.
Name the platform’s event contract. If the platform produces events, those events must conform to NL GOV CloudEvents v1.1 — the currently mandatory PTOLU version. The event type naming convention (e.g., nl.overheid.zaken.zaak-aangemaakt) and source URN (OIN-based) must be defined as platform-level architecture decisions.

About i8C’s Gemeente Integration Reference Solution
i8C is developing a vendor-neutral integration reference and starter solution for Dutch municipalities, aligned to all of the principles and standards described in this post. The solution provides a pre-built adapter catalogue (StUF, ZGW, Haal Centraal, DigiD/eHerkenning), a reusable LDV platform capability, and a NL GOV CloudEvents-compliant event backbone — all deployable as a reproducible, infrastructure-as-code-managed platform. For a detailed technical deep-dive including Azure Integration Services implementation, see our companion post on azureintegrationservice.com.

Sagar Sharma (author of the article), works as a solution architect with i8c and has helped various customers in designing and delivering GEMMA-aligned integration solutions using the full power of Azure Integration Services.

Reachout to us to plan an Architecture Discovery Session to map out your road to a vendor-neutral integration platform.