---
title: "Open Regiestandaard voor sociaal domein"
version: "1.0"
date: "2026-05-23"
license: "CC-BY-4.0"
license_url: "https://creativecommons.org/licenses/by/4.0/"
creator: "Fynqo"
creator_url: "https://fynqo.app"
canonical: "https://fynqo.app/open-regiestandaard"
language: "nl-NL"
keywords:
  - sociaal-domein
  - aanbesteding
  - regie
  - Wgs
  - vroegsignalering
  - bewindvoering
  - schuldhulpverlening
  - AVG
  - NEN-7510
  - MCP
  - open-standaard
citation: "Fynqo, Open Regiestandaard (CC-BY-4.0). https://fynqo.app/open-regiestandaard"
---

# Open Regiestandaard voor sociaal domein

> Een gratis, herbruikbare specificatie voor digitale coördinatie tussen
> schuldhulp, bewind, gemeenten, GGZ en woningcorporaties — onder CC-BY-4.0.
> Knip en plak in je aanbestedingsdocument.

## 1. Waarom een open standaard

In het Nederlandse sociaal domein werken meerdere instituties aan dezelfde
huishoudens. Schuldhulpverleners zien een aanmelding, gemeenten ontvangen
Wgs-vroegsignalen van energie- en waterleveranciers, bewindvoerders beheren
het leefgeld, GGZ-behandelaars werken aan herstel waarbij financiële stress
een blokkade vormt, en woningcorporaties signaleren huurachterstanden voordat
huisuitzettingen dreigen. Toch werken al deze partijen vrijwel altijd in
volledig gescheiden dossiers. Een signaal dat bij de gemeente binnenkomt
bereikt de bewindvoerder pas weken later, of helemaal niet. Een cliënt die
naar de schuldhulp wordt overgedragen herhaalt zijn verhaal opnieuw vanaf
nul. Een woningcorporatie ziet niet dat huurder X al bekend is bij het
wijkteam.

Dat is geen technologisch tekort, het is een ontwerp-tekort. Er bestaat
geen gedeelde specificatie waaraan systemen moeten voldoen om interoperabel
én AVG-conform met elkaar te kunnen werken. Elke leverancier maakt zijn
eigen keuzes, elke gemeente schrijft zijn eigen programma van eisen
opnieuw, en het resultaat is een gefragmenteerde markt waarin samenwerking
de uitzondering is in plaats van de regel.

De Open Regiestandaard sluit dat gat. Twaalf criteria die samen
minimumvereisten beschrijven voor coördinatie, consent, auditbaarheid en
data-portabiliteit. Geen marketing, geen vendor-lock-in: een publiek
artefact dat gemeenten in aanbestedingen kunnen plakken en dat leveranciers
— wie dan ook — kunnen invullen. De standaard is geschreven door Fynqo,
maar onder CC-BY-4.0 vrijgegeven aan iedereen die de meetlat wil
gebruiken.

## 2. De 12 criteria

Elk criterium is geschreven als toetsbare eis. De bullets onder elke titel
zijn sub-eisen die in een bid-evaluatie als afvinkpunten kunnen worden
gebruikt.

### 2.1 4-eyes payments (>€1.000)

- Elke uitgaande betaling boven €1.000 vereist twee onafhankelijke
  goedkeuringen door verschillende geauthenticeerde gebruikers.
- Initiator en approver mogen niet dezelfde persoon zijn; tijdstempel en
  user-ID worden onveranderlijk gelogd.
- Drempel is per organisatie configureerbaar, met €1.000 als
  minimum-baseline. Lagere drempels (bijvoorbeeld €500 voor bewindvoering
  rondom kwetsbare cliënten) zijn toegestaan.

### 2.2 Consent passport

- Toestemming per doelbinding (vroegsignalering, schuldhulp, bewind, GGZ,
  woningcorporatie) afzonderlijk vastgelegd.
- Cliënt kan elke consent zelfstandig intrekken via een eindgebruiker-portal;
  intrekking is direct effectief en wordt aan alle aangesloten systemen
  gepropageerd binnen 24 uur.
- Bewijslast van consent wordt cryptografisch verifieerbaar bewaard (hash +
  tijdstempel + actor + doelbinding).

### 2.3 Audit-log per state-transition

- Elke statuswijziging in een dossier of casus genereert één append-only
  log-entry: voor, na, actor, tijd, reden.
- Log is voor 7 jaar bewaarbaar (conform Awb-bewaartermijn voor
  gemeentelijke besluiten) en exporteerbaar als JSON-Lines.
- Geen retroactieve mutatie; correcties verschijnen als nieuwe entry met
  expliciete `corrects` verwijzing naar de oorspronkelijke entry.

### 2.4 AVG-by-design

- Data-minimalisatie: alleen velden die expliciet zijn gemotiveerd in het
  verwerkingsregister mogen worden opgeslagen.
- Pseudonimisering en versleuteling at-rest (AES-256) en in-transit
  (TLS 1.3) als default voor alle persoonsgegevens.
- DPIA-template en sub-verwerkers-lijst zijn als publiek artefact
  beschikbaar bij elke release.

### 2.5 Wgs-flow met 4-weken-termijn

- Inkomende vroegsignalen (energie, water, zorgverzekeraar, huur) worden
  gekoppeld aan een huishouden en triggeren een termijn-timer.
- De wettelijke 4-weken-termijn uit de Wet gemeentelijke schuldhulpverlening
  wordt zichtbaar bewaakt; escalatie bij T-7 dagen en T-0.
- Outreach-pogingen (brief, telefoon, huisbezoek) en uitkomst worden gelogd
  voor accountantscontrole en voor jaarlijkse Wgs-rapportage aan de raad.

### 2.6 NEN 7510-conform

- Informatiebeveiliging voor zorginformatie conform NEN 7510:2017 in
  combinatie met NEN 7512 (uitwisseling) en NEN 7513 (logging).
- Toegangsbeheer, autorisatie-matrix en incident-procedure zijn beschreven
  en jaarlijks getest.
- Externe ISMS-audit minimaal jaarlijks; auditrapport op verzoek
  beschikbaar voor de opdrachtgever.

### 2.7 GDPR-export in JSON

- Eindgebruiker kan via een self-service-portal een volledige GDPR-export
  (art. 20 AVG) opvragen in machine-leesbaar JSON.
- Export bevat ook gerelateerde audit-log-entries, consent-status en
  metadata, niet alleen formvelden.
- Levering binnen 30 dagen, kosteloos voor de eerste twee verzoeken per
  kalenderjaar conform AVG art. 12 lid 5.

### 2.8 MCP-server-ready voor agent-actionability

- Het systeem exposeert een Model Context Protocol (MCP) endpoint zodat
  AI-agents read/write-operaties kunnen aanroepen met expliciete
  consent-scopes en role-scopes.
- Discovery via `/.well-known/mcp.json` met versie, beschikbare tools en
  authenticatie-mechanisme.
- Tool-acties zijn idempotent en gelogd in de audit-log onder een aparte
  `agent` actor-type, gescheiden van menselijke acties.

### 2.9 Postcode-prefix-anonimisering in dashboards

- KPI- en rapportage-dashboards tonen geografische data op
  postcode-prefix-niveau (PC4 of grover), nooit op individueel adres.
- Onderliggende personen-data is alleen toegankelijk via expliciet
  doorklikken met audit-log van wie wanneer welk dossier inzag.
- Drempelwaarde: cellen met minder dan 5 huishoudens worden onderdrukt
  (k-anonimiteit, k=5).

### 2.10 RBAC tot rol-niveau

- Role-based access control met minimaal de rollen: cliënt, professional,
  manager, financiële controller, auditor.
- Per rol een autorisatie-matrix die per resource (dossier, betaling,
  rapportage) read/write/approve specificeert.
- Rol-toewijzingen worden gelogd; rol-rechten zijn niet runtime
  overrideable door de gebruiker zelf.

### 2.11 Role-based portal-isolatie

- Verschillende portalen (gemeente, schuldhulp, bewind, GGZ,
  woningcorporatie) delen één backend maar zijn UI-geïsoleerd.
- Cross-portal data-uitwisseling vereist expliciete
  consent-passport-handshake; geen impliciete federatie van data.
- Tenant-isolatie op database-rij-niveau met audit-trail bij cross-tenant
  queries (die alleen mogen plaatsvinden in expliciet gemandateerde
  scenario's).

### 2.12 Dossier-overdracht zonder dataverlies

- Bij overdracht naar een andere professional of organisatie wordt het
  volledige dossier (incl. audit-log en consent-passport) meegegeven.
- Ontvangende partij ziet de geschiedenis read-only; alleen nieuwe acties
  zijn schrijfbaar in haar eigen tenant.
- Standaard interoperabel formaat (JSON-LD met `Person`, `CaseFile`,
  `ConsentArtifact` als typen) zodat ook niet-Fynqo-vendors een dossier
  kunnen ontvangen en verwerken.

## 3. Hoe te gebruiken in een aanbesteding

### Stap 01 — Identificeer scope

Bepaal welke portals of uitvoeringscontexten (schuldhulp, bewind,
gemeente, woningcorporatie, GGZ, jongerenwerker, wijkteam) binnen de
aanbesteding vallen. Niet alle twaalf criteria zijn even relevant voor
elke scope. Een woningcorporatie-aanbesteding hoeft bijvoorbeeld niet alle
GGZ-specifieke eisen op te nemen; een gemeente die zich uitsluitend op
Wgs-vroegsignalering richt kan criterium 2.5 zwaarder wegen dan andere.

### Stap 02 — Kopieer criteria

Kopieer de relevante criteria-blokken (de twaalf sub-secties van hoofdstuk
2 hierboven) naar het programma van eisen van je aanbesteding. Dit is
toegestaan onder CC-BY-4.0; bronvermelding is voldoende. Je hoeft geen
toestemming te vragen, geen licentie-fee te betalen en geen
geheimhoudings-verklaring te tekenen.

### Stap 03 — Voeg eigen-context toe

Vul de criteria aan met gemeente-specifieke of organisatie-specifieke
parameters: drempelbedrag voor 4-eyes (bijvoorbeeld €500 in plaats van
€1.000), gewenste KPI-frequentie (real-time, dagelijks, maandelijks),
integratie-eisen met je bestaande burgerzaken-stack of zorgregistratie,
gewenste SLA-uptimes. De Open Regiestandaard is een baseline, geen
plafond.

### Stap 04 — Publiceer met attributie

Vermeld bij publicatie van het aanbestedingsdocument: "Gebaseerd op de
Open Regiestandaard van Fynqo (CC-BY-4.0), gepubliceerd op
fynqo.app/open-regiestandaard." Dit voldoet aan de licentie-eis van
CC-BY-4.0 (attribution required). Wijzigingen en aanvullingen mogen, mits
duidelijk is welk deel jouw bewerking is en welk deel uit de Open
Regiestandaard komt.

## 4. Vendor-neutraal

Deze specificatie is geschreven door Fynqo (CC-BY-4.0) maar voldoet niet
exclusief aan Fynqo's stack. Alternatieve leveranciers die aan deze
criteria voldoen zijn welkom; wij publiceren een open vergelijkingsmatrix
op https://fynqo.app/vergelijk waarin we Fynqo en andere
sociaal-domein-leveranciers naast elkaar leggen tegen exact deze twaalf
criteria.

Dat is geen schoonheidsfout. Een open standaard wint pas autoriteit als
hij ook door concurrenten kan worden ingevuld. De Fynqo-strategie is dat
de standaard rechtvaardig is en dat Fynqo zelf het beste invulling geeft
— niet dat alleen Fynqo aan de eisen kan voldoen. Gemeentelijke
inkopers die deze specificatie gebruiken voorkomen daarmee
vendor-lock-in: ze kunnen volgend jaar van leverancier wisselen zonder
hun programma van eisen opnieuw te hoeven schrijven.

Mocht je als leverancier menen dat een criterium oneerlijk is opgesteld
of een onbedoeld vendor-bias bevat, dan kun je een issue indienen via
https://fynqo.app/contact met onderwerp "Open Regiestandaard feedback".
Inhoudelijke kritiek wordt in een volgende versie verwerkt.

## 5. Download

- Markdown bron: https://fynqo.app/open-regiestandaard.md (dit bestand)
- Plain-text versie: https://fynqo.app/open-regiestandaard.txt
- DOCX versie: op aanvraag via https://fynqo.app/contact
- PDF versie: op aanvraag via https://fynqo.app/contact

De Markdown- en plain-text-versies zijn de canonieke bronbestanden. DOCX
en PDF worden op verzoek gegenereerd voor inkopers die deze formaten
nodig hebben voor hun aanbestedings-software.

## 6. Citeer als

> Fynqo, Open Regiestandaard (CC-BY-4.0).
> https://fynqo.app/open-regiestandaard
> Gepubliceerd: 2026-05-23.

Dit document is gepubliceerd onder de Creative Commons Attribution 4.0
International licentie (CC-BY-4.0). De volledige licentietekst:
https://creativecommons.org/licenses/by/4.0/legalcode.nl

### Wat mag je met dit document?

- **Delen** — kopiëren en doorgeven via elk medium of bestandsformaat.
- **Bewerken** — remixen, transformeren, en voortbouwen op het materiaal,
  voor elk doel, ook commercieel.

### Onder welke voorwaarden?

- **Naamsvermelding** — geef passende erkenning, verschaf een link naar
  de licentie, en geef aan of er wijzigingen zijn gemaakt. Je mag dit
  doen op redelijke wijze, maar niet zodanig dat het lijkt alsof Fynqo
  jouw gebruik onderschrijft.

## Versiebeheer

| Versie | Datum      | Wijziging                              |
|--------|------------|----------------------------------------|
| 1.0    | 2026-05-23 | Eerste publicatie. Twaalf criteria.    |

Toekomstige versies worden gepubliceerd op dezelfde URL met een
versietabel-update. Belangrijke wijzigingen worden aangekondigd via
https://fynqo.app/changelog en de RSS-feed
https://fynqo.app/rss/blog.xml.

---

*Einde document — Open Regiestandaard v1.0 — Fynqo — CC-BY-4.0.*