Security by design voor software- en IT-bedrijven
Security by design betekent dat beveiliging vanaf het ontwerp onderdeel is van uw product, in plaats van iets dat er achteraf omheen wordt gebouwd. Voor software- en IT-bedrijven is dat sinds kort geen keuze meer, want de Europese Cyber Resilience Act stelt er eisen aan.
Op deze pagina leest u wat de principes betekenen in uw ontwikkelstraat, welke data uit de Cyber Resilience Act op u afkomen, waarom IT-dienstverleners op twee manieren met de Cyberbeveiligingswet (CBW) te maken krijgen, en hoe u klantvragenlijsten sneller beantwoordt.
Wij komen deze vraag meestal tegen bij bedrijven die software maken of beheren en die van een klant een security-assessment kregen die zij niet konden invullen.
Wat security by design betekent voor een software- of IT-bedrijf
Het is geen maatregel maar een volgorde: beveiliging is een ontwerpkeuze, geen sluitstuk.
Het verschil is in de praktijk goed te zien. Een team dat achteraf beveiligt, voegt een inlogscherm toe aan een applicatie die intern uitgaat van vertrouwde gebruikers. Een team dat vanaf het ontwerp beveiligt, bepaalt eerst welke gegevens er zijn, wie daar bij mag en wat er gebeurt als iemand daar toch bij komt.
Voor uw organisatie heeft dat twee kanten. De productkant: wat u bouwt en oplevert aan klanten. En de eigen kant: hoe uw ontwikkelstraat, uw omgevingen en uw beheertoegang zijn ingericht. Klanten vragen inmiddels naar allebei.
Wat het oplevert is niet in de eerste plaats veiligheid. Het is snelheid in het verkooptraject. Wie kan laten zien hoe hij ontwikkelt, test en kwetsbaarheden afhandelt, komt door de leveranciersbeoordeling van een grote klant. Wie dat niet kan, blijft weken hangen in vragenlijsten.
De principes vertaald naar uw ontwikkelstraat
De principes zijn algemeen geformuleerd. Dit is wat ze concreet betekenen in het werk van uw team.
- Minimale rechten. Wat het concreet betekent: Elk onderdeel krijgt alleen de toegang die het nodig heeft. Waar het in uw straat landt: Servicekoppelingen, databaserechten, beheeraccounts.
- Veilig standaard. Wat het concreet betekent: De veilige instelling is de standaardinstelling, niet een optie. Waar het in uw straat landt: Installatiescripts, configuratiesjablonen, eerste inrichting bij de klant.
- Diepteverdediging. Wat het concreet betekent: Eén doorbroken maatregel mag niet het hele systeem openen. Waar het in uw straat landt: Netwerkindeling, validatie op meerdere lagen, scheiding van omgevingen.
- Beperk het aanvalsoppervlak. Wat het concreet betekent: Wat niet nodig is, staat uit of zit er niet in. Waar het in uw straat landt: Afhankelijkheden, ongebruikte endpoints, debugfuncties in productie.
- Ga uit van fouten. Wat het concreet betekent: Bij een storing valt het systeem terug naar veilig, niet naar open. Waar het in uw straat landt: Foutafhandeling, time-outs, gedrag bij falende authenticatie.
- Aantoonbaarheid. Wat het concreet betekent: Wat er gebeurt is achteraf te herleiden. Waar het in uw straat landt: Logging, versiebeheer, herleidbare uitrol naar productie.
De laatste rij is degene die het vaakst ontbreekt en die klanten het vaakst opvragen. Zonder logging en herleidbare uitrol kunt u bij een incident niet vertellen wat er is gebeurd.
Cyber Resilience Act: wat er wanneer van u wordt gevraagd
De Cyber Resilience Act stelt beveiligingseisen aan producten met digitale elementen. Dat is een brede definitie en de meeste software valt eronder.
De verordening is in december 2024 in werking getreden en wordt gefaseerd van toepassing. Dit zijn de momenten die uw planning bepalen.
- December 2024. Wat er gaat gelden: De verordening treedt in werking, de overgangsperiode start. Wat u nu al doet: Bepalen of en hoe uw producten eronder vallen.
- 11 september 2026. Wat er gaat gelden: De meldplicht voor actief misbruikte kwetsbaarheden en ernstige incidenten. Wat u nu al doet: Meldproces inrichten en beleggen wie meldt.
- 11 december 2027. Wat er gaat gelden: De volledige verordening, inclusief technische documentatie en conformiteit. Wat u nu al doet: Ontwikkelstraat en documentatie op orde brengen.
De eerste datum is de urgente. Vanaf dat moment moet u actief misbruikte kwetsbaarheden in uw product kunnen melden binnen korte termijnen. Dat vraagt geen nieuwe techniek maar wel een proces: wie beoordeelt, wie meldt, en hoe u dat vastlegt.
Belangrijk om te weten: de verordening raakt niet alleen fabrikanten. Ook importeurs en distributeurs krijgen verplichtingen, en wie software van een ander onder eigen naam levert, geldt al snel zelf als fabrikant. Meer over de verordening staat op de pagina over de Cyber Resilience Act.
Waarom IT-dienstverleners twee keer met de Cyberbeveiligingswet te maken krijgen
Softwarebedrijven en IT-dienstverleners zitten op twee manieren in deze wet, en dat wordt zelden uitgelegd.
De eerste route is direct. Aanbieders van bepaalde digitale diensten en beheerde ICT-diensten vallen zelf onder de Cyberbeveiligingswet, die vanaf 15 augustus 2026 geldt. Of dat voor u zo is, hangt af van wat u precies levert en van uw omvang.
De tweede route loopt via uw klanten. Organisaties die onder de wet vallen moeten hun toeleveringsketen beheersen. Dat vertalen zij naar eisen aan hun leveranciers, en u bent die leverancier. Zelfs als u niet direct onder de wet valt, komt de vraag dus alsnog bij u terecht.
In de praktijk merkt u de tweede route eerder dan de eerste. De vragenlijsten komen vaak al voordat de wet in werking treedt, omdat uw klanten hun eigen dossier op orde willen hebben.
Het praktische advies: ga er niet van uit dat u buiten schot blijft omdat u klein bent. Bepaal wel welke route op u van toepassing is, want dat bepaalt of u zelf een meldplicht heeft of alleen moet kunnen antwoorden.
Security in uw ontwikkelcyclus in zes stappen
Het doel is niet een apart securityproces naast uw ontwikkelproces. Het doel is dat het er onderdeel van wordt.
1. Breng uw producten en afhankelijkheden in kaart
Wij inventariseren wat u levert, welke componenten daarin zitten en welke daarvan van derden komen. U levert uw overzicht van repositories en afhankelijkheden. Dat levert het beeld op dat u sowieso nodig heeft voor de Cyber Resilience Act.
2. Bepaal de risico’s per product
Wij werken uit wat er mis kan gaan en wat de gevolgen zijn voor uw klanten. U betrekt de mensen die het product kennen. Dat levert de onderbouwing op voor de keuzes in het ontwerp, in plaats van een algemene checklist.
3. Leg de ontwerpeisen vast
Wij vertalen de principes naar concrete eisen die uw team kan toepassen. U bepaalt wat haalbaar is in uw architectuur. Dat levert eisen op die in de definition of done passen in plaats van in een beleidsdocument.
4. Bouw controles in de straat
Wij bepalen welke controles automatisch meelopen, zoals afhankelijkheidscontroles en scans op geheimen in code. U richt ze in samen met uw ontwikkelteam. Dat levert een straat op waarin fouten worden gevonden voordat ze in productie staan.
5. Richt kwetsbaarhedenbeheer in
Wij richten het proces in voor het ontvangen, beoordelen, oplossen en melden van kwetsbaarheden. U wijst aan wie beoordeelt en wie meldt. Dat levert het proces op dat de Cyber Resilience Act vanaf september 2026 van u vraagt.
6. Maak het aantoonbaar
Wij leggen de werkwijze vast in de vorm die auditors en klanten accepteren. U stelt het vast en houdt het bij. Dat levert het dossier op waarmee u vragenlijsten beantwoordt zonder elke keer opnieuw te beginnen.
Kwetsbaarheden ontvangen en afhandelen
Dit is het onderdeel dat vanaf september 2026 het snelst nodig is, en het is grotendeels organisatie.
U heeft een plek nodig waar iemand een kwetsbaarheid kan melden, en die plek moet vindbaar zijn. Een mailadres op uw website volstaat, mits het gelezen wordt. Veel bedrijven publiceren daarnaast een beleid waarin staat hoe zij met meldingen omgaan en binnen welke termijn zij reageren.
Vervolgens is er een beoordeling nodig. Is de melding terecht, hoe ernstig is het, welke versies zijn geraakt en zijn er klanten die actief risico lopen. Leg vast wie dat beoordeelt en binnen welke termijn.
Daarna volgt oplossen en informeren. Uw klanten moeten weten dat er een update is en waarom die belangrijk is. En bij actief misbruikte kwetsbaarheden komt de meldplicht in beeld, met korte termijnen.
Het gaat dus niet om een tool maar om een afspraak: een adres, een beoordelaar, een termijn en een manier om klanten te bereiken. Dat is in een week te regelen en het scheelt aanzienlijk als er iets speelt.
Klantvragenlijsten sneller beantwoorden
Elk softwarebedrijf krijgt ze en niemand heeft er tijd voor. Deze voorbereiding scheelt het meest.
- Een vaste beschrijving van uw ontwikkelproces, inclusief hoe code wordt beoordeeld en getest.
- Een overzicht van uw omgevingen en hoe die gescheiden zijn.
- Uw beleid voor toegang tot productie: wie mag erbij, hoe wordt dat verleend en beoordeeld.
- Uw kwetsbaarhedenproces: waar meldingen binnenkomen, wie beoordeelt en binnen welke termijn u oplost.
- Een actueel overzicht van de subverwerkers en clouddiensten die u gebruikt, met de regio waar gegevens staan.
- Uw incidentproces met de meldtermijnen die op u van toepassing zijn.
- Bewijs van uw laatste toets, bijvoorbeeld een penetratietest met opvolging en hertest.
- Uw back-up- en herstelafspraken, inclusief wanneer u herstel voor het laatst heeft getest.
Wie deze acht onderdelen één keer goed vastlegt, beantwoordt de meeste vragenlijsten in een uur in plaats van in een week. Het is bovendien vrijwel dezelfde set die u nodig heeft voor ISO 27001.
Security by design aantoonbaar maken in ISO 27001
De norm bevat maatregelen over veilig ontwikkelen. Die vormen samen precies de onderbouwing die klanten vragen.
Het gaat om afspraken over veilig ontwikkelen, over gescheiden ontwikkel-, test- en productieomgevingen, over beoordeling van code, over het beheersen van wijzigingen en over beveiliging bij uitbestede ontwikkeling. Een auditor vraagt daar het bewijs bij op: niet uw beleid, maar voorbeelden.
De praktische route is om de vastlegging te laten aansluiten op wat uw team toch al doet. Werkt u met pull requests en een goedkeuringsstap, dan is dat uw bewijs van codebeoordeling. Draait er een afhankelijkheidscontrole in de pijplijn, dan is dat uw bewijs van kwetsbaarhedenbeheer.
Wat meestal ontbreekt is de brug: het document dat uitlegt hoe uw werkwijze zich verhoudt tot de norm. Dat is een kwestie van opschrijven, niet van veranderen.
Wat de omvang van het traject bepaalt
Trajecten lopen uiteen van enkele weken tot een paar maanden. Deze factoren bepalen het verschil.
- Aantal producten en varianten. Elk product vraagt een eigen risicobeeld en eigen documentatie.
- Volwassenheid van uw ontwikkelstraat. Werkt u al met versiebeheer, reviews en een pijplijn, dan is het vooral vastleggen.
- Wel of geen eigen hosting. Levert u ook beheer, dan komen de eisen aan uw eigen omgeving erbij.
- Aantal afhankelijkheden van derden. Meer externe componenten betekent meer inventarisatie en meer bewaking.
- Valt u zelf onder de Cyberbeveiligingswet. Dat bepaalt of u een eigen meldplicht heeft of alleen moet kunnen antwoorden.
- Ambitie op certificering. Alleen vragenlijsten kunnen beantwoorden vraagt minder dan een certificeerbaar systeem.
Wij maken de omvang van uw traject inzichtelijk in een vrijblijvend gesprek.
Zo werkt QENSORA voor software- en IT-bedrijven
Wij vertalen de eisen naar uw ontwikkelproces. Wij schrijven geen code en wij nemen het ontwikkelwerk niet over.
Dat is bewust. Uw team kent het product en de architectuur beter dan wij ooit zullen doen. Wat er meestal ontbreekt is niet vakmanschap maar de vertaling: welke eis uit welke verordening of norm raakt welk onderdeel van uw werk, en welk bewijs hoort daarbij.
Wat wij toevoegen is dat wij zowel de techniek als de compliance-kant kennen. Een jurist kan u vertellen dat de Cyber Resilience Act een meldplicht kent, maar niet hoe u dat in uw pijplijn belegt. Een ontwikkelpartij kan het bouwen, maar niet beoordelen of het voldoet.
René van der Horst werkt dertig jaar in IT-leiderschap en begeleidt organisaties bij ISO 27001, de Cyberbeveiligingswet en de Cyber Resilience Act. Hij voert het eerste gesprek zelf, samen met iemand uit uw team.
Wilt u weten of uw product technisch standhoudt, dan is een penetratietest het passende middel. Wilt u breder zicht op waar u staat, kijk dan naar de gap-analyse.
Beveiliging als onderdeel van het product
Security by design klinkt als een principe en is in de praktijk een reeks kleine keuzes: welke rechten een koppeling krijgt, wat de standaardinstelling is, en wie er reageert als iemand een lek meldt.
Wilt u weten wat de Cyber Resilience Act voor uw product betekent en wat er vóór september geregeld moet zijn? Neem vrijblijvend contact op. In een eerste gesprek wordt meestal snel duidelijk of u eronder valt en wat er dan als eerste nodig is.
Veelgestelde vragen over security by design
Valt onze software onder de Cyber Resilience Act?
Waarschijnlijk wel. De verordening gaat over producten met digitale elementen, en dat is breed gedefinieerd. Er zijn uitzonderingen, onder meer voor bepaalde diensten die als clouddienst worden geleverd en voor sectoren met eigen regelgeving. Of uw product eronder valt, bepalen wij in een kort gesprek.
Wat verandert er op 11 september 2026?
Vanaf dat moment geldt de meldplicht uit de verordening voor actief misbruikte kwetsbaarheden en ernstige incidenten. Dat vraagt vooral een proces: een plek waar meldingen binnenkomen, iemand die beoordeelt, en een afspraak over wie meldt en binnen welke termijn.
Wij leveren alleen als clouddienst. Geldt dit dan ook?
Dat hangt af van hoe u levert. Software die uitsluitend als dienst wordt aangeboden valt onder omstandigheden buiten de verordening, maar levert u ook componenten, apps of on-premise installaties, dan komt u er alsnog mee te maken. Bovendien gelden er via de Cyberbeveiligingswet en via uw klanten alsnog eisen.
Is security by design hetzelfde als privacy by design?
Nee, al lijken ze op elkaar. Privacy by design komt uit de AVG en gaat over gegevensbescherming vanaf het ontwerp: dataminimalisatie, doelbinding en bewaartermijnen. Security by design gaat over de weerbaarheid van het product zelf. In de praktijk pakt u ze het beste samen op.
Moeten wij ISO 27001 hebben als softwarebedrijf?
Alleen als uw markt erom vraagt, en dat gebeurt in deze sector steeds vaker. Het voordeel is dat één certificaat een groot deel van de klantvragenlijsten vervangt. Het nadeel is dat het onderhoud vraagt. Krijgt u meerdere vragenlijsten per kwartaal, dan verdient het zich meestal terug.
Wat is een software bill of materials?
Een overzicht van alle componenten en afhankelijkheden in uw product, inclusief versies. Het is de basis om snel te kunnen bepalen of een nieuw ontdekte kwetsbaarheid u raakt. De Cyber Resilience Act verwacht dat u dit inzicht heeft, en het is ook zonder verordening praktisch onmisbaar.
Onze klant stuurt elke maand een andere vragenlijst. Wat helpt?
Leg één keer een vaste set antwoorden vast over uw ontwikkelproces, omgevingen, toegang, kwetsbaarhedenbeheer, subverwerkers, incidenten en uw laatste toets. De vragen verschillen per klant, de onderliggende onderwerpen niet. Daarmee gaat het invullen van weken naar uren.
Hoe beginnen wij als er nog niets is vastgelegd?
Met de inventarisatie van uw producten en afhankelijkheden, en met het kwetsbaarhedenproces. Die twee zijn het meest urgent vanwege de meldplicht en ze leveren direct waarde op. De rest kan gefaseerd, richting de datum waarop de verordening volledig van toepassing wordt.
Improved Security, Smarter Compliance.
Weten waar uw organisatie staat op het gebied van cybersecurity, compliance of IT? Of bent u benieuwd welke risico’s of verplichtingen voor uw organisatie relevant zijn?
Neem vrijblijvend contact op met QENSORA voor een kennismaking of adviesgesprek. Samen kijken we hoe uw organisatie veiliger en slimmer kan worden.
