Compliance by design: waarom regels vooraf in het ontwerp horen
Zo maak je veiligheid en privacy onderdeel van het ontwerp, in plaats van een controle aan het eind.
Kort antwoord
Compliance by design betekent dat je eisen uit wet- en regelgeving vanaf het begin in het ontwerp van een systeem opneemt, en ze niet achteraf toevoegt. Dat is het standpunt van PAQT. Het hoort vooraf, omdat veiligheid en privacy dan onderdeel zijn van het ontwerp en niet van een losse controle. Wat er voor jouw organisatie precies bij hoort, hangt af van je situatie en van de regels die voor jou gelden.
Veel organisaties kijken pas naar privacy, beveiliging en regelgeving als een systeem al grotendeels staat. Bij organisaties waar de regeldruk groeit, zoals in zorg en financiële dienstverlening, vinden wij dat te laat. In deze blog leggen we uit wat compliance by design is en waarom we het vooraf doen. Aan het eind staan vijf vragen die je vóór een project kunt stellen.
Wat is compliance by design?
Wij verstaan onder compliance by design een werkwijze waarbij het voldoen aan regels een vast onderdeel is van het ontwerp en het bouwproces, en niet een controle aan het eind.
Welke regels gelden, hangt af van je sector en toepassing. Voorbeelden zijn de AVG (Algemene verordening gegevensbescherming, over het omgaan met persoonsgegevens), NIS2 (Europese regels voor de cyberveiligheid van organisaties) en de AI-verordening (de Europese regels voor AI).
Wij kijken daarbij naar drie onderdelen:
- Data: verschillende gegevens vragen om verschillende bescherming.
- Infrastructuur: de basis van goede beveiliging, fysiek en digitaal. Lokaal waar dat moet, schaalbaar waar dat kan.
- Governance: de processen, structuren en verantwoordelijkheden die ervoor zorgen dat veiligheid na oplevering blijft werken. Technisch kan alles op orde zijn, maar zonder governance blijft veiligheid onzeker.
Waarom begin je vooraf en niet achteraf?
Omdat naleving moeilijker wordt als je pas laat kijkt. Wij vinden dat privacy en beveiliging niet als losse onderdelen achteraf moeten worden beoordeeld: de keuzes over data en infrastructuur zijn dan al gemaakt. Compliance is ook geen eenmalige check. Zonder blijvende aandacht schuift het na de oplevering weer naar de achtergrond.
Wanneer het anders kan: bij een bestaand systeem kun je niet opnieuw ontwerpen. Begin dan met in kaart brengen welke data, systemen en verantwoordelijkheden er zijn, en pak de grootste gaten eerst aan.
Wanneer worden eisen zichtbaar? Het voorbeeld van UWV
Het UWV, de uitkeringsinstantie die mensen helpt aan werk, stopte in oktober 2026 met een groot ICT-project. Het ging om de Bemiddelingsservice, waarvoor sinds 2021 circa 55 miljoen euro is besteed. UWV noemt als redenen dat problemen met de gegevenskwaliteit en de technische inpassing in de loop van het project steeds zichtbaarder werden, dat de aanpak onvoldoende paste bij het vernieuwende karakter van het project en dat het vertrouwen ontbrak in invoering binnen een aanvaardbare termijn en tegen verantwoorde kosten. Het Adviescollege ICT-toetsing, dat het project op verzoek van UWV onderzocht, adviseerde in februari 2026 om in kleine stappen te werken en eerst vast te stellen of de applicatie voldoende toegevoegde waarde heeft. Het noemt ook dat de applicatie data uitwisselt met andere UWV-systemen en moet voldoen aan de AI-verordening.
Wat de uiteindelijke oorzaak ook blijkt te zijn, de leverancier ziet de datakwaliteit van UWV als oorzaak en UWV gaat het project nog evalueren. Het voorbeeld raakt aan een vraag die wij belangrijk vinden: wanneer wordt zichtbaar wat een systeem eigenlijk nodig heeft? Bij UWV was dat volgens UWV zelf pas in de loop van het project.
Wij vinden dat je eisen over data, techniek en wet- en regelgeving zo vroeg mogelijk zichtbaar moet maken en moet toetsen. Die gedachte, eisen vooraf in het ontwerp meenemen, ligt ook aan compliance by design ten grondslag.
Vijf vragen om vooraf te stellen
Dit is ons eigen kader. Het is een hulpmiddel, geen juridisch advies.
- Welke regels gelden voor dit systeem, en wie beoordeelt dat? Leg vast wie in de organisatie dat bepaalt, en laat het toetsen door een jurist of compliance officer.
- Welke data verwerkt het, en welke bescherming hoort erbij? Per soort gegevens kan dat verschillen.
- Waar draait het? Welke onderdelen moeten lokaal blijven en welke kunnen schalen?
- Wie is verantwoordelijk na oplevering? Welke processen zorgen dat de afspraken ook na de livegang blijven gelden?
- Hoe toets je vroeg? Bijvoorbeeld met een prototype of een kleine test, en met vooraf afgesproken punten waarop je bijstuurt of stopt.
Hoe wij hiernaar kijken
PAQT is een softwareontwikkelaar die zich richt op organisaties waar de regeldruk groeit, zoals in zorg en financiële dienstverlening. Ons doel is dat veiligheid en vertrouwen de basis vormen van de dienstverlening van onze opdrachtgevers, en compliance by design is voor ons een uitgangspunt sinds de oprichting. In ons werk toetsen we ontwerpen vroeg bij eindgebruikers, bijvoorbeeld met klikbare prototypes, zodat afwijkingen zichtbaar worden voordat er veel tijd en geld in zit. Dat is onze manier van werken en geen garantie dat elk project slaagt. Meer over onze kijk op regelgeving lees je op onze pagina Voldoen aan AVG/NIS2, en over onze werkwijze op Onze aanpak.
Afsluiting
Wie compliance pas aan het eind bekijkt, ontdekt eisen laat. Wie ze vooraf in het ontwerp opneemt, ontdekt ze vroeg. Dit is een kader voor je eigen afweging, geen vaste route, en welke regels voor jou gelden hangt af van je situatie. Regelgeving verandert, dus controleer de actuele stand voordat je erop bouwt.