Cybersecurity bij maatwerksoftware: wat we vanaf de eerste sprint meenemen

Laten jullie software ontwikkelen die klantgegevens, financiële informatie of medische dossiers verwerkt? Dan wil je niet vlak voor de livegang ontdekken dat de beveiliging tekortschiet.

Beveiliging die je achteraf toevoegt, is lastig en duur. Keuzes over toegangsrechten, opslag en koppelingen zitten dan al diep in de code verweven. Daarom nemen we beveiliging vanaf de eerste sprint mee, in het ontwerp en in de ontwikkeling.

Eerst afspraken, dan code

Nog voordat er een regel code is geschreven, maken we met jullie een paar afspraken. Ze lijken administratief, maar ze bepalen veel van wat we daarna technisch kiezen.

De eerste vraag is welke gegevens de applicatie verwerkt en wie erbij moet kunnen. Namen en adressen vragen een andere bescherming dan financiële of medische gegevens, dus brengen we in kaart welke informatie de applicatie nodig heeft en voor wie. Verwerken we persoonsgegevens namens jullie, dan sluiten we een verwerkersovereenkomst en maken we afspraken die aansluiten bij de AVG.

Daarna gaat het over de plek. Waar staan de gegevens, wie kan bij die omgeving, en gaat er iets naar diensten buiten Europa? Bij hosting en externe diensten kijken we naar de opslaglocatie, naar doorgifte buiten de Europese Economische Ruimte en naar de beveiligingsafspraken met die leveranciers.

En dan het eigendom. Code, content en data zijn van jullie en blijven dat. We ontwikkelen met gangbare technologie en letten op de licenties van onderdelen van anderen, zodat jullie niet vastzitten aan één leverancier.

De basis in elke applicatie

Welke maatregelen een applicatie nodig heeft, hangt af van wat er op het spel staat. Een intern hulpmiddel vraagt iets anders dan een platform met medische dossiers of betalingen. Deze zes onderdelen bekijken we bij elke applicatie vanaf het begin.

Dezelfde zes maatregelen, steeds zwaarder naarmate er meer op het spel staat.

Rollen en rechten. Iedere gebruiker ziet en doet alleen wat nodig is voor het eigen werk: een medewerker van de klantenservice hoeft geen financiële gegevens aan te passen. Een knop of scherm verbergen is daarvoor niet genoeg. De applicatie controleert bij elke actie op de achtergrond opnieuw of iemand die mag uitvoeren. Wie de rollen vanaf het begin goed ontwerpt, hoeft de rechten later niet door de hele applicatie heen aan te passen. Fouten in toegangsrechten staan niet voor niets opnieuw bovenaan de OWASP Top 10 van 2025, de internationale lijst van de grootste beveiligingsrisico’s in webapplicaties.

Inloggen met een tweede stap. Een sterk wachtwoord helpt, maar niet meer zodra het gestolen of gelekt is. Met multifactorauthenticatie (MFA) bevestigt een gebruiker het inloggen ook via een app op de telefoon of een fysieke beveiligingssleutel. Vooral bij gevoelige gegevens en bij accounts met veel rechten maakt dat verschil.

Versleuteling. Gegevens die onderweg worden onderschept, of opslag waar iemand onbevoegd bij komt, mogen niets leesbaars opleveren. Daarom versleutelen we op twee plekken: tijdens het transport via beveiligde verbindingen zoals HTTPS, en waar nodig in de opslag, van databases en bestanden tot back-ups. Wachtwoorden bewaren we helemaal niet. We slaan alleen een berekende vingerafdruk op (een hash), waarmee je een wachtwoord wel kunt controleren maar niet kunt terughalen.

Vastleggen wie wat deed. Bij gevoelige processen wil je kunnen terugzien wie een dossier aanpaste, rechten wijzigde of een betaling goedkeurde, en wanneer. Dat legt een audit-log vast. Het helpt bij het onderzoeken van een incident en bij interne controle. Die log is zelf ook beschermd, en er komt niet meer gevoelige informatie in dan nodig.

Testen op zwakke plekken. Ook een fout in de code kan iemand toegang geven waar die geen recht op heeft. We controleren daarom alles wat gebruikers invoeren, zodat niemand via een invoerveld opdrachten naar de database kan sturen (een SQL-injectie), en we gaan zorgvuldig om met de sleutels waarmee de applicatie andere systemen benadert. Daarnaast leunt elke applicatie op tientallen softwareonderdelen van anderen. Wordt daarin een lek gevonden, dan raakt dat de hele applicatie. Automatische controles op bekende lekken, code reviews en gerichte beveiligingstests vinden zwakke plekken vroeg. Bij een hoger risico kan een onafhankelijke penetratietest verstandig zijn: een externe partij die gericht probeert binnen te komen.

Back-ups die terug te zetten zijn. Goede beveiliging maakt een incident minder waarschijnlijk, niet onmogelijk. Een menselijke fout, een storing of ransomware kan nog steeds toeslaan. Daarom spreken we af welke gegevens een back-up krijgen, hoe die back-ups beschermd zijn tegen inzien en verwijderen, en hoe snel de applicatie weer moet draaien. Een back-up telt pas als je hebt geprobeerd hem terug te zetten.

Hoe veilig een applicatie in de praktijk blijft, hangt ook af van de werkwijze eromheen: tests, monitoring en kleine releases. Meer daarover lees je in welke DevOps-practices essentieel zijn voor maatwerk.

Koppelingen en AI krijgen alleen wat ze nodig hebben

Elke koppeling met een ander systeem is een deur naar jullie gegevens. We ontwikkelen koppelingen daarom bij voorkeur in een aparte laag, los van de kern van de applicatie. Zo is per koppeling te regelen wie er binnen mag en welke gegevens er uitgaan. Een externe dienst hoeft geen volledig klantdossier te zien als een paar gegevens volstaan. De sleutels waarmee koppelingen inloggen, bewaren we veilig en zijn te vervangen zodra dat nodig is.

Een planningsdienst krijgt via de koppellaag alleen naam, adres en afspraaktijd. De rest van het dossier blijft binnen.

Voor AI geldt hetzelfde principe. Bij een AI-implementatie blijven jullie gegevens in jullie eigen omgeving. Per vraag gaat alleen mee wat nodig is, en elk antwoord verwijst naar de bron waarop het is gebaseerd. Hoe je data daarvoor klaarmaakt, staat in onze checklist voor AI op eigen data. Vooraf leggen we samen vast waaraan een goed antwoord moet voldoen, zodat de kwaliteit meetbaar is. AI stelt voor, de vakspecialist beslist: een AI-antwoord wijzigt nooit zomaar gevoelige gegevens en neemt geen definitieve besluiten.

Beveiliging is na de livegang niet af

Een applicatie die vandaag goed beveiligd is, kan dat over een jaar niet meer zijn. Er worden nieuwe lekken gevonden, medewerkers wisselen van rol en koppelingen veranderen. Het tempo gaat bovendien omhoog: volgens het Cybersecuritybeeld Nederland 2026 zetten aanvallers AI in bij elke stap van een aanval.

Bronnen: Verizon Data Breach Investigations Report 2026 en NCSC.

Servers die we beheren, onderhouden we wekelijks en monitoren we dagelijks, en kritieke updates zetten we direct door. Hoe dat gaat als het spannend wordt, lees je in ons stuk over het PHP-lek PHP2Shell.

Wat er verder nodig is, verschilt per klant. Een intern dashboard vraagt iets anders dan een klantportaal waar gebruikers dag en nacht op rekenen. Leg in elk geval vooraf vast wie in actie komt bij een incident. Valt jullie organisatie onder de Cyberbeveiligingswet, dan zijn een risicoanalyse en passende maatregelen sinds 15 augustus 2026 ook wettelijk verplicht.

Staat er bij jullie een maatwerkapplicatie op de planning? In de Verkenningssprint onderzoeken we in vier weken of het idee functioneel en technisch haalbaar is, met de keuzes rond architectuur en beveiliging erbij. Je krijgt een klikbaar prototype, een begroting en een eerlijk go/no-go-advies.