Wat moet er in een acceptable use policy staan?

Geplaatst op: 21 september 2026

Een acceptable use policy (AUP) beschrijft welke regels gelden voor het gebruik van ICT-middelen binnen een organisatie: van laptops en e-mail tot cloudapplicaties en bedrijfsnetwerken. De kern van een goede AUP bestaat altijd uit een duidelijke omschrijving van toegestaan en niet-toegestaan gebruik, de verantwoordelijkheden van medewerkers, en de gevolgen bij overtreding. In dit artikel beantwoorden we de meest gestelde vragen over het opstellen en onderhouden van een effectief AUP-beleid.

Wat zijn de verplichte onderdelen van een acceptable use policy?

Een acceptable use policy moet minimaal bevatten: een beschrijving van de scope (welke systemen en medewerkers vallen eronder), de gedragsregels voor het gebruik van ICT-middelen, de rechten en plichten van medewerkers, de gevolgen bij overtreding, en een verwijzing naar gerelateerd beleid zoals een wachtwoordbeleid of incidentprocedure. Zonder deze bouwstenen is een AUP juridisch en praktisch onvolledig.

Concreet betekent dit dat een goede AUP de volgende elementen bevat:

• Doelstelling en scope: voor wie geldt het beleid en op welke systemen, apparaten en diensten is het van toepassing
• Toegestaan gebruik: wat medewerkers mogen doen met bedrijfsmiddelen, inclusief privégebruik als dat is toegestaan
• Verboden gebruik: expliciet verboden handelingen, zoals het installeren van ongeautoriseerde software, het delen van inloggegevens of het bezoeken van bepaalde categorieën websites
• Beveiliging en wachtwoorden: basisregels voor wachtwoordbeheer, vergrendeling van apparaten en omgang met gevoelige gegevens
• Monitoring en privacy: in hoeverre de organisatie het gebruik monitort en hoe dit zich verhoudt tot de privacyrechten van medewerkers
• Sancties: welke maatregelen volgen bij overtreding, van een waarschuwing tot ontslag of aangifte
• Verwijzingen: links naar gerelateerd beleid, zoals een clean desk policy, remote work policy of NIS2-compliance beleid

Organisaties die onder de NIS2-richtlijn vallen, zijn bovendien verplicht om beleid voor informatiebeveiliging structureel te documenteren. Een AUP is daarin een basisonderdeel, maar vormt altijd onderdeel van een breder geheel aan maatregelen.

Waarom verschilt een acceptable use policy per organisatie?

Een AUP verschilt per organisatie omdat de risico’s, de branche, het type medewerkers en de gebruikte systemen sterk uiteenlopen. Een zorginstelling die werkt met patiëntgegevens heeft andere regels nodig dan een creatief bureau waar medewerkers vrijelijk internettoegang nodig hebben. De inhoud van een AUP moet altijd aansluiten op de werkelijkheid van de organisatie.

Factoren die bepalen hoe een AUP eruitziet:

• Sector en regelgeving: organisaties in de zorg, financiële sector of overheid hebben te maken met sectorspecifieke wet- en regelgeving die eisen stelt aan het gebruik van systemen en gegevens
• Werkwijze: werken medewerkers op kantoor, hybride of volledig remote? Dit bepaalt mede welke regels rondom netwerktoegang en apparatuur nodig zijn
• Type medewerkers: een organisatie met veel externe inhuurkrachten of stagiairs heeft andere overwegingen dan een bedrijf met alleen vaste medewerkers
• Risicoprofiel: organisaties die regelmatig doelwit zijn van cyberaanvallen of die kritieke infrastructuur beheren, hebben strengere regels nodig
• Cultuur: een te strenge AUP die niet past bij de organisatiecultuur wordt niet nageleefd; het beleid moet realistisch en uitvoerbaar zijn

Een AUP kopiëren van internet of van een andere organisatie is dan ook een veelgemaakte fout. Het resultaat is een document dat niet aansluit op de praktijk en daardoor al snel als papieren tijger eindigt.

Hoe lang en gedetailleerd moet een acceptable use policy zijn?

Een acceptable use policy moet lang genoeg zijn om alle relevante situaties te dekken, maar kort genoeg om door medewerkers daadwerkelijk gelezen en begrepen te worden. In de praktijk is een AUP van twee tot vijf pagina’s voor de meeste organisaties voldoende. Technische details horen thuis in aparte technische richtlijnen, niet in de AUP zelf.

Het doel van een AUP is gedragsverandering en bewustwording, niet het uitputtend vastleggen van elke technische maatregel. Een te lang document werkt averechts: medewerkers slaan het over, begrijpen het niet volledig of onthouden de kern niet.

Een goede vuistregel is: schrijf de AUP op het niveau van de gemiddelde medewerker, niet op het niveau van de IT-afdeling. Gebruik begrijpelijke taal, vermijd jargon waar mogelijk, en voeg concrete voorbeelden toe bij regels die anders voor interpretatie vatbaar zijn. Denk aan: “Je mag geen software installeren zonder toestemming van IT” in plaats van “Het is verboden ongeautoriseerde executables te deployen op bedrijfseigendommen.”

Technische specificaties, zoals welke poorten geblokkeerd zijn of hoe de monitoring technisch werkt, horen thuis in afzonderlijke technische documentatie. De AUP verwijst daar eventueel naar, maar neemt die inhoud niet over.

Welke gedragsregels horen thuis in een acceptable use policy?

De gedragsregels in een AUP richten zich op het gebruik van e-mail, internet, software, apparaten en bedrijfsgegevens. Concreet gaat het om regels over wachtwoordbeheer, het gebruik van privéapparaten voor werk, social media, het delen van vertrouwelijke informatie en de omgang met verdachte berichten of phishing.

De meest voorkomende gedragsregels in een AUP zijn:

• E-mail en communicatie: geen vertrouwelijke informatie versturen via onbeveiligde kanalen, geen zakelijke e-mail gebruiken voor persoonlijke doeleinden die reputatieschade kunnen veroorzaken
• Wachtwoorden en toegang: nooit inloggegevens delen, gebruik van sterke wachtwoorden of een wachtwoordmanager, vergrendelen van apparaten bij afwezigheid
• Software en downloads: alleen goedgekeurde software installeren, geen illegale software of content downloaden
• Privéapparaten (BYOD): als privéapparaten zijn toegestaan voor werk, welke beveiligingseisen gelden er dan en welke bedrijfsgegevens mogen erop staan
• Social media: wat medewerkers wel en niet mogen delen over de organisatie, collega’s of klanten
• Verdachte situaties: hoe te handelen bij een phishingmail, verdachte link of beveiligingsincident
• Gegevensopslag: waar bedrijfsgegevens mogen worden opgeslagen (alleen in goedgekeurde cloudomgevingen, niet op privé-opslagdiensten)

Organisaties die regelmatig pentests of phishingsimulaties uitvoeren, merken vaak dat juist de regels rondom verdachte e-mails en wachtwoorden in de praktijk het minst worden nageleefd. Dat maakt het extra belangrijk om deze regels concreet en herkenbaar te formuleren.

Hoe zorg je dat medewerkers de acceptable use policy naleven?

Naleving van een acceptable use policy begint met bewustwording: medewerkers moeten de AUP kennen, begrijpen waarom de regels bestaan, en weten wat de gevolgen zijn bij overtreding. Een AUP die eenmalig bij indiensttreding wordt ondertekend maar nooit meer ter sprake komt, heeft nauwelijks effect op het daadwerkelijke gedrag.

Effectieve manieren om naleving te bevorderen:

• Onboarding: bespreek de AUP actief bij indiensttreding, laat medewerkers tekenen voor ontvangst en begrip
• Regelmatige herhaling: verwijs naar de AUP tijdens beveiligingstrainingen, teamvergaderingen of bij het uitrollen van nieuwe systemen
• Bewustwordingstrainingen: trainingen over phishing, wachtwoordveiligheid en veilig internetgebruik maken de regels tastbaar en relevant
• Technische ondersteuning: maak naleving gemakkelijk door technische maatregelen die het gewenste gedrag ondersteunen, zoals een wachtwoordmanager beschikbaar stellen of automatische schermvergrendeling instellen
• Duidelijke meldprocedure: medewerkers moeten weten hoe en waar ze verdachte situaties kunnen melden, zonder angst voor negatieve gevolgen
• Consequent handhaven: als overtredingen geen gevolgen hebben, verliest de AUP zijn geloofwaardigheid; zorg voor een duidelijk en consistent sanctiebeleid

Naleving is geen eenmalige actie maar een doorlopend proces. Organisaties die investeren in continue security awareness zien in de praktijk een aanzienlijk betere naleving van hun ICT-beleid.

Wanneer moet een acceptable use policy worden herzien?

Een acceptable use policy moet minimaal eens per jaar worden herzien, en altijd direct na een significante verandering in de organisatie of het dreigingslandschap. Denk aan de introductie van nieuwe technologie, een fusie, een beveiligingsincident, of nieuwe wet- en regelgeving zoals de NIS2-richtlijn.

Concrete aanleidingen voor een herziening zijn onder meer:

• Introductie van nieuwe systemen, cloudplatforms of samenwerkingstools
• Wijziging in de werkwijze, zoals de overstap naar hybride werken
• Een beveiligingsincident waarbij bleek dat de AUP tekortschoot
• Nieuwe wet- of regelgeving die eisen stelt aan het gebruik van systemen of gegevens
• Uitbreiding of krimp van de organisatie, fusies of overnames
• Feedback van medewerkers of de IT-afdeling over onduidelijkheden in het beleid

In 2026 is het bijhouden van beleid extra relevant voor organisaties die onder de Cyberbeveiligingswet (de Nederlandse uitwerking van NIS2) vallen. Die wet verplicht organisaties om beleid voor risicoanalyse en informatiebeveiliging actueel te houden als onderdeel van de zorgplicht. Een verouderde AUP is daarbij niet alleen een praktisch risico, maar kan ook juridische consequenties hebben.

Stel bij elke herziening ook de vraag of de AUP nog aansluit bij de dagelijkse praktijk. Een beleid dat op papier klopt maar in de werkelijkheid niet wordt gevolgd, biedt geen echte bescherming.

Hoe Q-Cyber helpt met het opstellen van een acceptable use policy

Een AUP opstellen klinkt eenvoudig, maar in de praktijk worstelen veel organisaties met de vraag hoe concreet het beleid moet zijn, hoe het aansluit op andere beleidsdocumenten en hoe het juridisch en technisch klopt. Wij helpen organisaties bij het volledige traject, van de eerste analyse tot een werkbaar en nageleefd beleid.

Wat wij daarin bieden:

• Beleidsschrijving op maat: wij schrijven een AUP die aansluit op jouw organisatie, branche en risicoprofiel, zonder gebruik van generieke templates
• NIS2-alignment: wij zorgen dat het beleid voldoet aan de eisen van de Cyberbeveiligingswet en de NIS2-zorgplicht, inclusief afstemming op gerelateerde beleidsdocumenten
• Bewustwordingstrainingen: wij verzorgen trainingen voor medewerkers en bestuurders om naleving te verankeren in de organisatiecultuur
• Onafhankelijk advies: wij zijn niet gebonden aan softwarepartijen of leveranciers, wat betekent dat ons advies altijd in het belang van jouw organisatie is
• Periodieke review: via onze vCISO-diensten houden wij beleid actueel en signaleren wij tijdig wanneer herziening nodig is

Wil je weten hoe jouw huidige AUP scoort of heb je hulp nodig bij het opstellen van cybersecuritybeleid? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Wat is het verschil tussen NIS2 en DORA?

Geplaatst op: 20 september 2026

NIS2 en DORA zijn twee verschillende Europese regelgevingen op het gebied van cybersecurity, maar ze richten zich op andere doelgroepen en hebben een andere reikwijdte. NIS2 geldt breed voor essentiële en belangrijke sectoren in de EU, terwijl DORA specifiek van toepassing is op de financiële sector. Voor organisaties in de financiële sector kunnen beide regelgevingen tegelijk van toepassing zijn. Dit artikel beantwoordt de meest gestelde vragen over het verschil tussen NIS2 en DORA, zodat je precies weet wat er voor jouw organisatie geldt.

Voor welke organisaties geldt NIS2 en voor welke DORA?

NIS2 geldt voor organisaties in een breed scala aan essentiële en belangrijke sectoren, zoals energie, transport, drinkwater, gezondheidszorg, digitale infrastructuur en overheid. DORA, de Digital Operational Resilience Act, geldt uitsluitend voor de financiële sector: banken, verzekeraars, beleggingsondernemingen, betalingsinstellingen en hun kritieke ICT-dienstverleners.

In Nederland vallen naar schatting ruim 10.000 organisaties rechtstreeks onder NIS2. Dat zijn niet alleen grote bedrijven, maar ook middelgrote organisaties die actief zijn in sectoren die als essentieel of belangrijk worden aangemerkt. Denk aan ziekenhuizen, drinkwaterbedrijven, aanbieders van digitale diensten en overheidsinstanties zoals gemeenten, provincies en waterschappen. Gemeenten vallen automatisch onder de wet, net als ministeries en waterschappen.

DORA richt zich op een specifiekere groep. De verordening is op 17 januari 2025 volledig van toepassing geworden en geldt voor alle financiële entiteiten die onder Europees financieel toezicht staan. Een belangrijk onderscheid met NIS2 is dat DORA een EU-verordening is en dus rechtstreeks werkt in alle lidstaten, zonder nationale omzetting. NIS2 is een richtlijn die via nationale wetgeving wordt geïmplementeerd. In Nederland gebeurt dat via de Cyberbeveiligingswet, waarvan de inwerkingtreding wordt verwacht in het tweede kwartaal van 2026.

Wat zijn de belangrijkste inhoudelijke verschillen tussen NIS2 en DORA?

Het grootste inhoudelijke verschil tussen NIS2 en DORA zit in de diepgang en focus. NIS2 legt brede cybersecurityverplichtingen op aan een groot aantal sectoren, terwijl DORA specifiek gericht is op de operationele digitale weerbaarheid van financiële instellingen en daarin op bepaalde punten veel verder gaat dan NIS2.

Wat regelt NIS2?

NIS2 verplicht organisaties om cybersecurityrisico’s structureel te beheersen. De kernverplichtingen omvatten:

• Implementeren van technische en organisatorische beveiligingsmaatregelen
• Beleid voor toegangsbeheer, cryptografie en systeembeveiliging
• Supply chain-beveiliging: inzicht in de cybersecuritymaatregelen van leveranciers
• Incidentmelding bij de bevoegde autoriteiten
• Bestuurlijke verantwoordelijkheid: het management is eindverantwoordelijk en moet aantoonbaar voldoende kennis hebben van cybersecurity

Bij niet-naleving kunnen essentiële entiteiten boetes krijgen tot 10 miljoen euro of 2% van de wereldwijde jaaromzet. Voor belangrijke entiteiten geldt een maximum van 7 miljoen euro of 1,4% van de jaaromzet.

Wat regelt DORA?

DORA gaat dieper in op specifieke thema’s die voor de financiële sector extra relevant zijn. De verordening bevat gedetailleerde eisen op het gebied van:

• ICT-risicobeheer: een uitgebreid raamwerk voor het identificeren, beschermen, detecteren en herstellen van ICT-risico’s
• Testen van digitale weerbaarheid: inclusief verplichte dreigingsgestuurde penetratietests (TLPT) voor grote instellingen
• Beheer van ICT-derde partijen: strikte contractuele eisen aan kritieke ICT-leveranciers, met directe toezichtsbevoegdheden van Europese toezichthouders over die leveranciers
• Informatie-uitwisseling over cyberdreigingen binnen de financiële sector

DORA is daarmee veel gedetailleerder en sectorspecifieker dan NIS2, met name op het gebied van leveranciersmanagement en het testen van weerbaarheid.

Overlappen NIS2 en DORA elkaar, of vullen ze elkaar aan?

NIS2 en DORA overlappen elkaar gedeeltelijk, maar vullen elkaar ook aan. Voor financiële instellingen die onder beide regelgevingen vallen, geldt dat DORA op de overlappende gebieden voorrang heeft. De Europese wetgever heeft dit expliciet bepaald: DORA wordt beschouwd als een sectorspecifieke aanvulling op NIS2 voor de financiële sector.

In de praktijk betekent dit dat een bank die voldoet aan DORA op het gebied van ICT-risicobeheer en incidentmelding, daarmee ook grotendeels voldoet aan de overeenkomstige NIS2-verplichtingen. De DORA-eisen zijn op die punten strenger en gedetailleerder, waardoor naleving van DORA als voldoende wordt beschouwd voor de overlappende onderdelen van NIS2.

Toch zijn er ook gebieden waarop NIS2 aanvullende verplichtingen oplegt die DORA niet dekt. Denk aan de bredere zorgplicht voor de beveiliging van netwerk- en informatiesystemen en de specifieke eisen rondom bestuurlijke verantwoordelijkheid zoals die in de Nederlandse Cyberbeveiligingswet worden uitgewerkt. Financiële instellingen moeten dus beide regelgevingen goed kennen en begrijpen waar ze overlappen en waar ze van elkaar afwijken.

Wat zijn de meldplichten onder NIS2 vergeleken met DORA?

Zowel NIS2 als DORA bevatten strikte meldplichten bij ernstige incidenten, maar de termijnen en structuur verschillen. Onder NIS2 moeten organisaties een significant incident binnen 24 uur melden bij de bevoegde autoriteit, gevolgd door een aanvullende melding binnen 72 uur en een eindverslag binnen een maand. DORA hanteert vergelijkbare termijnen, maar kent een gedetailleerdere classificatie van wat als een ernstig incident geldt.

Onder NIS2 is de meldstructuur als volgt:

1. Vroegtijdige waarschuwing: binnen 24 uur na ontdekking van een significant incident
2. Vervolgmelding: aanvullende informatie binnen 72 uur
3. Eindverslag: gedetailleerde beschrijving van het incident, de ernst en de gevolgen, uiterlijk één maand na de eerste melding

DORA kent een vergelijkbare fasering, maar voegt daar een initiële kennisgeving aan toe die al binnen vier uur na classificatie van het incident moet plaatsvinden, gevolgd door een tussentijdse en een eindrapportage. Bovendien moeten financiële instellingen onder DORA ook hun klanten informeren als het incident hen raakt. Dit maakt de DORA-meldplicht operationeel zwaarder dan die van NIS2.

Voor de publieke sector in Nederland zijn de verwachte meldpunten het NCSC (rijksoverheid), de Informatiebeveiligingsdienst voor gemeenten en CERT-Watermanagement voor waterschappen. Voor de financiële sector zijn de relevante toezichthouders de Europese Bankautoriteit, de Europese Autoriteit voor verzekeringen en bedrijfspensioenen en de Europese Autoriteit voor effecten en markten.

Hoe bereid je je voor op zowel NIS2 als DORA tegelijk?

Als jouw organisatie onder zowel NIS2 als DORA valt, is de slimste aanpak om te beginnen met een geïntegreerde gap-analyse die beide regelgevingen tegelijk in kaart brengt. Zo voorkom je dubbel werk en kun je maatregelen slim combineren. Begin met de DORA-vereisten als basis, omdat die op de overlappende gebieden strenger zijn, en vul daarna aan met de specifieke NIS2-verplichtingen die DORA niet dekt.

Praktische stappen voor een gecombineerde voorbereiding:

• Bepaal je scope: Identificeer onder welke categorie je valt (essentieel of belangrijk onder NIS2, en welk type financiële entiteit onder DORA)
• Voer een gap-analyse uit: Breng in kaart welke maatregelen al zijn geïmplementeerd en waar de lacunes zitten ten opzichte van beide regelgevingen
• Stel een geïntegreerd beleidskader op: Ontwikkel beleid dat beide regelgevingen dekt, zodat je niet twee aparte trajecten hoeft te doorlopen
• Breng de toeleveringsketen in kaart: Zowel NIS2 als DORA stellen eisen aan de beveiliging van leveranciers; een gecombineerde aanpak bespaart tijd
• Train je bestuurders: Beide regelgevingen leggen verantwoordelijkheid bij het management; zorg dat zij de risico’s kennen en kunnen beoordelen
• Test je weerbaarheid: DORA verplicht dreigingsgestuurde penetratietests voor grote instellingen; een professionele pentest helpt ook NIS2-compliance aantonen
• Richt incidentmeldprocedures in: Zorg dat je processen de termijnen van beide regelgevingen kunnen halen

Voor organisaties die nog niet weten of en hoe ze onder NIS2 vallen, biedt de NIS2 Zelfevaluatietool van de RVO een goed startpunt. Financiële instellingen doen er verstandig aan ook de richtsnoeren van de Europese toezichthouders te raadplegen voor de DORA-implementatie. Wie nu al actief bezig is met cybersecurity onderzoek en beleidsvorming, staat straks veel sterker wanneer beide regelgevingen volledig van kracht zijn.

Hoe Q-Cyber helpt met NIS2 en DORA compliance

Wij begrijpen dat het navigeren door twee overlappende Europese regelgevingen tegelijk complex en tijdrovend is. Q-Cyber helpt organisaties om dit overzichtelijk en pragmatisch aan te pakken, zonder onnodige bureaucratie. Onze aanpak is concreet:

• Gap-analyse NIS2 en DORA: We brengen in kaart waar jouw organisatie nu staat en wat er nog moet gebeuren om aan beide regelgevingen te voldoen
• Beleidsschrijving op maat: We schrijven beleid dat aansluit op jouw risicoprofiel en voldoet aan de eisen van NIS2 en DORA
• Bestuurderstrainingen: We verzorgen trainingen die voldoen aan de trainingsplicht onder NIS2 en bestuurders in staat stellen weloverwogen beslissingen te nemen
• Technisch testen: Via red teaming en penetratietests toetsen we of jouw technische maatregelen in de praktijk standhouden
• Virtuele CISO: Via Continuous-Q bieden we doorlopende begeleiding door een team van specialisten, zonder dat je een fulltime CISO hoeft aan te nemen

We werken volledig onafhankelijk, zonder binding aan softwarepartijen of andere toeleveranciers. Dat betekent dat ons advies altijd in jouw belang is. Wil je weten wat er voor jouw organisatie nodig is? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Hoe pak je kwetsbaarhedenbeheer aan voor NIS2?

Geplaatst op: 19 september 2026

Kwetsbaarhedenbeheer is een van de concrete verplichtingen die voortvloeien uit de NIS2-richtlijn. Organisaties die onder de Cyberbeveiligingswet vallen, moeten aantonen dat zij actief risico’s identificeren, beoordelen en aanpakken. Maar hoe doe je dat in de praktijk? In dit artikel doorloop je stap voor stap hoe je een solide aanpak voor kwetsbaarhedenbeheer opzet die aansluit bij de eisen van NIS2 compliance.

De NIS2-zorgplicht vereist passende technische en organisatorische maatregelen op basis van een risicobeoordeling. Kwetsbaarhedenbeheer, ofwel vulnerability management, is daarbinnen een essentieel onderdeel. Een gestructureerde aanpak helpt je niet alleen aan de wet te voldoen, maar versterkt ook daadwerkelijk je digitale weerbaarheid.

Breng je huidige kwetsbaarheden in kaart

Begin met een volledig overzicht van je digitale omgeving. Je kunt geen kwetsbaarheden beheren die je niet kent. Dit betekent dat je eerst inzicht moet krijgen in alle systemen, netwerken, applicaties en koppelingen die binnen je organisatie actief zijn, inclusief cloudoplossingen en externe leveranciers.

1. Stel een actuele inventarisatie op van alle IT-assets: servers, werkstations, netwerkapparatuur, applicaties en cloudservices.
2. Voer een vulnerability scan uit op je omgeving om technische zwakheden automatisch te detecteren.
3. Combineer geautomatiseerde scans met een handmatige beoordeling van configuraties, toegangsrechten en verouderde software.
4. Betrek ook je toeleveringsketen: NIS2 stelt uitdrukkelijk eisen aan supply chain security, dus kwetsbaarheden bij leveranciers tellen mee.

Na deze stap heb je een overzicht van alle bekende kwetsbaarheden in je omgeving. Controleer of de inventarisatie compleet is: zijn er systemen die buiten scope zijn gebleven? Zijn schaduw-IT-omgevingen meegenomen? Een onvolledig beeld leidt tot blinde vlekken die later problemen geven.

Prioriteer kwetsbaarheden op risico en impact

Niet elke kwetsbaarheid vraagt om directe actie. Met een lange lijst van bevindingen is het verleidelijk om alles tegelijk aan te pakken, maar dat is niet realistisch. Prioritering op basis van risico en impact maakt je aanpak beheersbaar en effectief.

1. Gebruik een erkend scoringssysteem zoals CVSS (Common Vulnerability Scoring System) als startpunt voor de technische ernst van een kwetsbaarheid.
2. Weeg de score af tegen de context van je organisatie: een kwetsbaarheid in een publiek bereikbaar systeem weegt zwaarder dan dezelfde kwetsbaarheid in een geïsoleerd intern systeem.
3. Houd rekening met de beschikbaarheid, integriteit en vertrouwelijkheid van de betrokken data of dienst. Dit zijn de kernbegrippen uit de NIS2-zorgplicht.
4. Categoriseer kwetsbaarheden in prioriteitsklassen: kritiek, hoog, gemiddeld en laag, en koppel daar maximale hersteltermijnen aan.

Met een geprioriteerde lijst weet je waar je energie naartoe moet. Verifieer de prioritering door die voor te leggen aan een technisch verantwoordelijke én een beleidsverantwoordelijke binnen je organisatie. Zo zorg je dat zowel de technische als de bedrijfsmatige impact is meegewogen.

Stel een herstelplan op per kwetsbaarheid

Een herstelplan maakt de stap van bevinding naar actie concreet. Voor elke kwetsbaarheid bepaal je wie verantwoordelijk is, wat de maatregel is en wanneer die gereed moet zijn. Dit is ook de documentatie die je nodig hebt om aan te tonen dat je als organisatie in control bent, iets wat toezichthouders zoals de Rijksinspectie Digitale Infrastructuur (RDI) kunnen opvragen.

1. Wijs per kwetsbaarheid een eigenaar aan: de persoon of het team dat verantwoordelijk is voor het herstel.
2. Bepaal de herstelmaatregel: patch installeren, configuratie aanpassen, toegangsrechten beperken, of een tijdelijke mitigatie als directe oplossing niet mogelijk is.
3. Stel een realistische deadline vast op basis van de prioriteitsklasse. Kritieke kwetsbaarheden vragen om herstel binnen dagen, niet weken.
4. Documenteer de beslissing inclusief de onderbouwing. Als je bewust kiest voor een tijdelijke mitigatie, leg dan vast waarom en wanneer de definitieve oplossing volgt.

Het herstelplan is ook een communicatiemiddel richting het bestuur. Onder de Cyberbeveiligingswet zijn bestuurders verantwoordelijk voor beslissingen over informatiebeveiliging. Een helder plan helpt hen weloverwogen keuzes te maken, wat aansluit bij de trainingsplicht die de wet voor bestuurders voorschrijft. Meer weten over hoe je beleid en compliance structureel inricht? Dat vraagt om een integrale aanpak.

Verifieer herstel en documenteer de resultaten

Herstel afsluiten zonder verificatie is een veelgemaakte fout. Een patch kan zijn uitgerold zonder correct te zijn toegepast, of een configuratiewijziging kan onbedoeld nieuwe problemen introduceren. Verificatie sluit de cirkel en levert tegelijk de bewijslast die je nodig hebt voor NIS2 compliance.

1. Voer na elk herstel een hertest uit op de specifieke kwetsbaarheid. Dit kan via een gerichte scan of een handmatige controle, afhankelijk van de aard van de maatregel.
2. Controleer of de kwetsbaarheid daadwerkelijk is opgelost en of er geen nieuwe bevindingen zijn ontstaan door de wijziging.
3. Leg de uitkomst vast: datum van herstel, wie de verificatie heeft uitgevoerd en het resultaat van de hertest.
4. Sluit de bevinding formeel af in je registratiesysteem en koppel de documentatie aan de originele bevinding.

Na verificatie heb je een aantoonbaar gesloten cyclus: van ontdekking via herstel naar bevestigde oplossing. Dit is precies de soort gestructureerde verantwoording die toezichthouders verwachten. Bewaar de documentatie minimaal conform de bewaartermijnen die in je sector gelden.

Maak kwetsbaarhedenbeheer een doorlopend proces

Kwetsbaarhedenbeheer is geen project met een einddatum, maar een continu proces. Nieuwe systemen worden toegevoegd, software-updates introduceren nieuwe kwetsbaarheden en het dreigingslandschap verandert voortdurend. De NIS2-richtlijn verwacht dan ook een structurele aanpak, niet een eenmalige exercitie.

1. Plan regelmatige scans in, minimaal kwartaalgewijs, en vaker voor kritieke systemen of na grote wijzigingen in de omgeving.
2. Koppel kwetsbaarhedenbeheer aan je bredere risicobeheerproces: nieuwe risico’s uit de risicoanalyse moeten leiden tot gerichte scans of beoordelingen.
3. Stel KPI’s in voor je herstelproces, zoals het percentage kwetsbaarheden dat binnen de afgesproken termijn is opgelost.
4. Evalueer het proces periodiek: wat werkt goed, waar lopen herstelacties vast en hoe kan de samenwerking tussen teams worden verbeterd?

Een doorlopend proces vraagt ook om doorlopend inzicht. Overweeg proactief onderzoek naar nieuwe dreigingen als aanvulling op periodieke scans, zodat je niet alleen reageert op bekende kwetsbaarheden maar ook vooruitkijkt naar opkomende risico’s. Met een levend kwetsbaarhedenbeheerproces bouw je de dynamische weerbaarheid op die NIS2 beoogt.

Hoe Q-Cyber helpt met kwetsbaarhedenbeheer voor NIS2

Een gestructureerd kwetsbaarhedenbeheerproces opzetten en volhouden vraagt om technische kennis, beleidsmatige inbedding en continue aandacht. Wij ondersteunen organisaties bij elke stap van dit traject, van de eerste inventarisatie tot een doorlopende beheercyclus die aansluit bij de eisen van de NIS2-richtlijn.

• Vulnerability scans en pentests: Wij voeren technische scans en red team-oefeningen uit om kwetsbaarheden in je omgeving bloot te leggen, inclusief aanvallen via de toeleveringsketen.
• Prioritering en hersteladvies: Onze consultants helpen je bevindingen te wegen op risico en impact, en stellen een praktisch herstelplan op dat aansluit bij jouw organisatiecontext.
• Beleid en documentatie: Wij schrijven het beleid dat je nodig hebt voor NIS2 compliance en zorgen dat je herstelcyclus aantoonbaar is voor toezichthouders.
• Continuous-Q: Via ons virtueel CISO-programma borgen we kwetsbaarhedenbeheer als doorlopend proces binnen jouw organisatie, zonder dat je daar zelf een fulltime specialist voor hoeft aan te nemen.
• Onafhankelijk en transparant: Wij zijn niet gebonden aan softwarepartijen of leveranciers, zodat ons advies altijd in jouw belang is.

Wil je weten waar jouw organisatie nu staat en welke stappen het meest urgent zijn? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Hoe stel je een informatiebeveiligingsbeleid op?

Geplaatst op: 18 september 2026

Een informatiebeveiligingsbeleid opstellen begint met het vastleggen van de doelstellingen, scope, verantwoordelijkheden en maatregelen die jouw organisatie hanteert om informatie te beschermen. Het beleid vormt de schriftelijke basis waarop alle overige beveiligingsmaatregelen en procedures steunen. In dit artikel beantwoorden we de meest gestelde vragen over het schrijven van een sterk informatiebeveiligingsbeleid, van de inhoud tot de aansluiting op NIS2-verplichtingen.

Wat moet er in een informatiebeveiligingsbeleid staan?

Een informatiebeveiligingsbeleid bevat minimaal de beveiligingsdoelstellingen van de organisatie, de scope van het beleid, de rolverdeling en verantwoordelijkheden, de risicobereidheid en de maatregelen die worden ingezet om informatie te beschermen. Daarnaast hoort er een verwijzing in te staan naar onderliggende procedures en een beschrijving van hoe het beleid wordt gehandhaafd en getoetst.

In de praktijk ziet een goed informatiebeveiligingsbeleid er als volgt uit:

• Doelstelling en context: Waarom bestaat dit beleid en welke waarden beschermt het?
• Scope: Op welke systemen, processen, locaties en medewerkers is het beleid van toepassing?
• Principes en uitgangspunten: De kernbeginselen zoals vertrouwelijkheid, integriteit en beschikbaarheid (de CIA-triade).
• Rollen en verantwoordelijkheden: Wie is waarvoor verantwoordelijk, van bestuur tot eindgebruiker?
• Risicobereidheid: Welk niveau van risico accepteert de organisatie?
• Maatregelen: Een overzicht van de technische en organisatorische beveiligingsmaatregelen.
• Incidentbeheer: Hoe wordt omgegaan met beveiligingsincidenten?
• Naleving en handhaving: Hoe wordt gecontroleerd of het beleid wordt nageleefd?
• Verwijzingen: Links naar onderliggende procedures, werkinstructies en standaarden zoals ISO 27001 of de BIO2.

Het beleid hoeft geen technisch handboek te zijn. Het is een strategisch document dat richting geeft. De technische details horen thuis in onderliggende procedures en werkinstructies. Houd de taal toegankelijk zodat iedereen in de organisatie begrijpt wat er van hen wordt verwacht.

Hoe bepaal je de scope van je informatiebeveiligingsbeleid?

De scope van een informatiebeveiligingsbeleid bepaal je door in kaart te brengen welke informatiesystemen, processen, locaties en medewerkers onder het beleid vallen. Een goede scope is zo breed dat alle kritieke informatie wordt gedekt, maar zo concreet dat het beleid uitvoerbaar blijft. Begin altijd met een inventarisatie van de informatie die de organisatie verwerkt en de risico’s die daarbij horen.

Bij het bepalen van de scope spelen de volgende vragen een rol:

• Welke informatiesystemen en applicaties verwerken gevoelige of kritieke gegevens?
• Welke bedrijfsprocessen zijn afhankelijk van die systemen?
• Zijn er externe partijen, leveranciers of cloudproviders die toegang hebben tot jouw informatie?
• Welke locaties of afdelingen zijn relevant, inclusief thuiswerkers?
• Welke wet- en regelgeving is van toepassing, zoals de AVG of de Cyberbeveiligingswet?

Een veelgemaakte fout is het opstellen van een beleid dat op papier alles omvat, maar in de praktijk nergens concreet op ingaat. Kies liever een heldere, afgebakende scope die je daadwerkelijk kunt handhaven. Als de organisatie groeit of de dienstverlening verandert, pas je de scope aan bij de eerstvolgende herziening.

Voor organisaties die onder de NIS2-regelgeving vallen, is het bijzonder belangrijk om de toeleveringsketen mee te nemen in de scope. De zorgplicht vereist namelijk inzicht in de cybersecuritymaatregelen van leveranciers die toegang hebben tot jouw systemen of gegevens.

Wie is verantwoordelijk voor het informatiebeveiligingsbeleid?

De eindverantwoordelijkheid voor het informatiebeveiligingsbeleid ligt bij het bestuur of de directie van de organisatie. Het dagelijks beheer en de uitvoering worden doorgaans belegd bij een Chief Information Security Officer (CISO) of een vergelijkbare functionaris. Lijnmanagers zijn verantwoordelijk voor de naleving binnen hun eigen afdeling of domein.

Een heldere rolverdeling ziet er in de meeste organisaties als volgt uit:

• Bestuur of directie: Stelt het beleid vast, draagt eindverantwoordelijkheid en zorgt voor voldoende budget en prioriteit.
• CISO of Information Security Officer (ISO): Ontwikkelt, beheert en actualiseert het beleid en adviseert het bestuur.
• Lijnmanagers: Zorgen dat medewerkers het beleid kennen en naleven.
• Medewerkers: Handelen conform het beleid en melden afwijkingen of incidenten.
• IT-afdeling: Implementeert de technische maatregelen die voortvloeien uit het beleid.

Onder de Cyberbeveiligingswet (de Nederlandse implementatie van NIS2) is de bestuurlijke verantwoordelijkheid voor informatiebeveiliging wettelijk verankerd. Voor overheidsorganisaties is dat de politieke leiding, zoals ministers of wethouders. Bestuurders zijn verplicht een training te volgen om beveiligingsrisico’s te kunnen herkennen en beoordelen. Dit maakt informatiebeveiliging nadrukkelijk een boardroomonderwerp en geen louter technische aangelegenheid.

Hoe vaak moet een informatiebeveiligingsbeleid worden herzien?

Een informatiebeveiligingsbeleid moet minimaal jaarlijks worden herzien. Daarnaast is een tussentijdse herziening noodzakelijk na ingrijpende veranderingen in de organisatie, de technologie of de dreigingsomgeving. Denk aan een overname, een nieuwe cloudstrategie, een ernstig beveiligingsincident of nieuwe wet- en regelgeving.

Jaarlijkse herziening is de standaard die wordt gehanteerd in gangbare normenkaders zoals ISO 27001 en de Baseline Informatiebeveiliging Overheid (BIO2). Bij die herziening stel je jezelf de volgende vragen:

• Is de scope nog actueel, of zijn er nieuwe systemen, processen of leveranciers bijgekomen?
• Zijn de verantwoordelijkheden nog correct belegd?
• Zijn er nieuwe dreigingen of kwetsbaarheden die om aanpassing vragen?
• Zijn er incidenten geweest waaruit lessen zijn getrokken die in het beleid moeten worden verwerkt?
• Zijn er wettelijke of regelgevende wijzigingen die impact hebben op het beleid?

Het vastleggen van de herzieningsdatum en de versiehistorie in het document zelf is een goede praktijk. Zo is altijd aantoonbaar wanneer het beleid voor het laatst is beoordeeld en welke wijzigingen zijn doorgevoerd. Dit is ook relevant voor toezichthouders die willen zien dat informatiebeveiliging actief wordt beheerd en niet slechts op papier bestaat.

Wat is het verschil tussen een informatiebeveiligingsbeleid en een beveiligingsprocedure?

Een informatiebeveiligingsbeleid beschrijft wat de organisatie wil bereiken en waarom, terwijl een beveiligingsprocedure beschrijft hoe dat in de praktijk wordt uitgevoerd. Het beleid is strategisch en richtinggevend; de procedure is operationeel en stap-voor-stap.

Het onderscheid is eenvoudig te illustreren aan de hand van een voorbeeld. Het informatiebeveiligingsbeleid stelt dat toegang tot gevoelige systemen uitsluitend is voorbehouden aan geautoriseerde medewerkers. De bijbehorende procedure beschrijft vervolgens hoe een toegangsaanvraag wordt ingediend, wie die aanvraag goedkeurt, hoe toegang wordt ingetrokken bij vertrek en hoe dit wordt geregistreerd.

De hiërarchie ziet er in de meeste organisaties als volgt uit:

1. Beleid: Het overkoepelende document met doelstellingen, principes en verantwoordelijkheden.
2. Standaarden en richtlijnen: Specificeren de minimale eisen en aanbevelingen per onderwerp, zoals wachtwoordbeleid of versleutelingsstandaarden.
3. Procedures: Stap-voor-stap beschrijvingen van hoe specifieke taken worden uitgevoerd.
4. Werkinstructies: Gedetailleerde instructies voor specifieke systemen of handelingen.

Een veelgemaakte fout is het samenvoegen van beleid en procedures in één document. Dit maakt het document onnodig lang, moeilijk te onderhouden en lastig te communiceren. Houd beide gescheiden en zorg voor duidelijke verwijzingen vanuit het beleid naar de onderliggende procedures.

Hoe sluit een informatiebeveiligingsbeleid aan op NIS2-verplichtingen?

Een informatiebeveiligingsbeleid sluit aan op NIS2-verplichtingen door expliciet de zorgplicht te adresseren die de Cyberbeveiligingswet oplegt. Dat betekent dat het beleid aantoonbaar ingaat op risicobeheersing, toegangsbeheer, cryptografie, incidentbeheer, bedrijfscontinuïteit en supply chain-beveiliging. NIS2 vereist niet alleen dat maatregelen worden genomen, maar ook dat cybersecurity structureel is ingebed in beleid, processen en bestuur.

De NIS2-richtlijn, die in Nederland wordt omgezet via de Cyberbeveiligingswet (Cbw), stelt concrete eisen aan de inhoud van het beveiligingsbeleid. De volgende elementen moeten aantoonbaar zijn geborgd:

• Risicoanalyse en beleid: Een gedocumenteerde aanpak voor het identificeren en beheersen van cybersecurityrisico’s.
• Incidentbeheer: Procedures voor detectie, respons en melding van beveiligingsincidenten, inclusief de verplichting om ernstige incidenten binnen 24 uur te melden bij de bevoegde autoriteit.
• Bedrijfscontinuïteit: Maatregelen voor back-up, herstel en crisisbeheersing.
• Supply chain-beveiliging: Inzicht in en eisen aan de cybersecuritymaatregelen van leveranciers.
• Toegangsbeheer en cryptografie: Beleid voor wie toegang heeft tot welke systemen en hoe gegevens worden versleuteld.
• Bestuurlijke verantwoordelijkheid: Aantoonbare betrokkenheid van het bestuur, inclusief het volgen van een verplichte training.

Voor overheidsorganisaties biedt de BIO2 een praktisch normenkader dat grotendeels de NIS2-zorgplicht invult. Organisaties die al werken conform de BIO2 hebben daarmee een solide basis voor NIS2-compliance. Voor private organisaties biedt ISO 27001 een vergelijkbaar houvast. In beide gevallen geldt dat het beleid niet alleen moet bestaan, maar ook aantoonbaar moet worden uitgevoerd en periodiek getoetst.

Hoe Q-Cyber helpt met het opstellen van een informatiebeveiligingsbeleid

Een goed informatiebeveiligingsbeleid opstellen vraagt om meer dan een sjabloon invullen. Het vereist inzicht in de specifieke risico’s van jouw organisatie, kennis van de geldende wet- en regelgeving en de vaardigheid om beleid te schrijven dat zowel bestuurlijk gedragen als operationeel uitvoerbaar is. Wij combineren technische expertise met beleidsmatige kennis en helpen organisaties concreet verder:

• Wij voeren een gap-analyse uit om te bepalen welke onderdelen van het beleid ontbreken of onvoldoende zijn uitgewerkt.
• Wij schrijven een op maat gemaakt informatiebeveiligingsbeleid dat aansluit op jouw sector, risicoprofiel en eventuele NIS2-verplichtingen.
• Wij verzorgen trainingen voor bestuurders die voldoen aan de trainingsplicht onder de Cyberbeveiligingswet.
• Via onze Continuous-Q dienstverlening bieden wij een virtuele CISO die het beleid actief beheert, actualiseert en bewaakt.
• Wij adviseren pragmatisch en onafhankelijk, zonder binding aan softwarepartijen of toeleveranciers.

Of je nu voor het eerst een informatiebeveiligingsbeleid opstelt of een bestaand beleid wilt versterken met het oog op NIS2: wij helpen je verder. Neem contact op voor een vrijblijvend gesprek over jouw situatie.

Lees meer

Wat is een security baseline?

Geplaatst op: 17 september 2026

Een security baseline is een minimumset van beveiligingsmaatregelen die een organisatie verplicht toepast op alle systemen, netwerken en processen. Het is het vertrekpunt voor cybersecurity: de ondergrens waaronder geen enkel systeem mag zakken. Elke organisatie die serieus omgaat met IT-beveiliging heeft zo’n baseline nodig, ongeacht haar omvang of sector. In dit artikel beantwoorden we de meest gestelde vragen over het opstellen, onderhouden en toepassen van een cybersecurity baseline.

Waarom hebben organisaties een security baseline nodig?

Organisaties hebben een security baseline nodig omdat, zonder een vastgesteld minimumniveau van beveiliging, ieder systeem en ieder team zijn eigen aanpak hanteert, wat onvermijdelijk leidt tot blinde vlekken en inconsistente bescherming. Een beveiligingsbaseline zorgt voor een gedeeld fundament waarop alle verdere beveiligingsmaatregelen worden gebouwd.

In de praktijk zien we dat cyberaanvallen maar al te vaak binnenkomen via de zwakste schakel: een server zonder patchbeheer, een account zonder multi-factorauthenticatie, of een afdeling die nooit een bewustwordingstraining heeft gevolgd. Een IT-beveiligingsbaseline sluit die zwakke plekken systematisch af door voor de hele organisatie dezelfde basisvereisten te stellen.

Daarnaast is een security baseline steeds vaker een wettelijke verplichting. Onder de NIS2-richtlijn en de Cyberbeveiligingswet moeten organisaties aantoonbaar passende technische en organisatorische maatregelen nemen. Een gedocumenteerde en geïmplementeerde baseline vormt het bewijs dat een organisatie haar zorgplicht serieus neemt. Voor overheden geldt bovendien de Baseline Informatiebeveiliging Overheid (BIO2) als verplicht normenkader.

Tot slot maakt een baseline het gesprek over cybersecurity behapbaar. In plaats van eindeloze discussies over welke maatregel wel of niet nodig is, biedt de baseline een helder referentiekader voor bestuurders, IT-teams en auditors.

Wat hoort er in een security baseline thuis?

Een security baseline bevat de minimale beveiligingsmaatregelen die voor alle systemen en medewerkers binnen een organisatie gelden, ongeacht het specifieke risicoprofiel van een afdeling of applicatie. Denk aan patchbeheer, toegangsbeheer, encryptie, logging en bewustwording.

Concreet bestaat een volledige cybersecurity baseline doorgaans uit de volgende onderdelen:

• Toegangsbeheer: sterke wachtwoorden, multi-factorauthenticatie en het principe van minimale rechten (least privilege)
• Patchbeheer: tijdig installeren van beveiligingsupdates voor alle systemen en software
• Encryptie: versleuteling van gegevens in transit en in rust, inclusief beleid voor het gebruik van cryptografie
• Logging en monitoring: vastleggen van relevante gebeurtenissen en actief bewaken op afwijkingen
• Netwerksegmentatie: scheiden van systemen zodat een aanvaller niet vrij door het netwerk kan bewegen
• Back-up en herstel: regelmatige, geteste back-ups en een gedocumenteerd herstelproces
• Bewustwording: periodieke training voor medewerkers over phishing, social engineering en veilig gedrag
• Supply chain-beveiliging: inzicht in de beveiligingsmaatregelen van leveranciers en partners
• Incidentrespons: een beschreven proces voor het detecteren, melden en afhandelen van beveiligingsincidenten

Welke specifieke normen en drempelwaarden je hanteert, hangt af van het gekozen referentiekader. Gangbare kaders zijn ISO 27002, de BIO2 voor overheidsorganisaties of het NIST Cybersecurity Framework. Belangrijk is dat de baseline niet alleen technisch van aard is: organisatorische en beleidsmatige maatregelen zijn minstens zo essentieel.

Hoe stel je een security baseline op?

Je stelt een security baseline op door eerst een risicoanalyse uit te voeren, vervolgens een passend normenkader te kiezen, de minimummaatregelen te definiëren en deze te documenteren en te implementeren. Het is een gestructureerd proces dat start vanuit de risico’s van de organisatie, niet vanuit een willekeurige lijst met technische maatregelen.

Stap 1: Breng de context en risico’s in kaart

Inventariseer welke systemen, gegevens en processen kritisch zijn voor de organisatie. Stel vast welke dreigingen realistisch zijn en wat de potentiële impact is van een beveiligingsincident. Deze risicoanalyse vormt de onderbouwing voor de keuzes die je later maakt.

Stap 2: Kies een normenkader als basis

Gebruik een erkend kader als startpunt, zoals ISO 27002, de BIO2 of het NIST Cybersecurity Framework. Zo hoef je niet alles zelf te bedenken en kun je aantonen dat je baseline is gebaseerd op breed geaccepteerde standaarden. Voor organisaties die onder de NIS2 vallen, biedt de mapping van NIS2-maatregelen ten opzichte van ISO 27002 en de BIO een handig overzicht van verplichte, optionele en situationele maatregelen.

Stap 3: Definieer de minimummaatregelen

Vertaal de uitkomsten van je risicoanalyse en het gekozen normenkader naar concrete, meetbare maatregelen. Formuleer ze zo specifiek dat een IT-beheerder precies weet wat er van hem verwacht wordt. Denk aan: “Alle accounts met beheerdersrechten maken gebruik van multi-factorauthenticatie” in plaats van “Toegangsbeveiliging is op orde.”

Stap 4: Documenteer, communiceer en implementeer

Een baseline die alleen op papier bestaat, heeft geen waarde. Zorg voor draagvlak bij bestuurders en IT-teams, leg de baseline vast in beleid, en zet een implementatieplan op. Een penetratietest of vulnerability scan kan helpen om te toetsen of de geïmplementeerde maatregelen daadwerkelijk werken zoals bedoeld.

Wat is het verschil tussen een security baseline en een security policy?

Een security baseline beschrijft de minimale technische en organisatorische maatregelen die een organisatie verplicht implementeert. Een security policy is het overkoepelende beleidsdocument dat de doelstellingen, verantwoordelijkheden en uitgangspunten van de informatiebeveiliging vastlegt. De baseline is dus een concrete uitwerking van de policy.

Vergelijk het met een bouwproject: de security policy is het bestemmingsplan dat bepaalt wat er mag worden gebouwd en waarom. De security baseline is het bouwbesluit dat de minimale technische eisen vastlegt waaraan elk gebouw moet voldoen. Beide zijn nodig, maar ze opereren op een ander abstractieniveau.

In de praktijk betekent dit het volgende onderscheid:

• Security policy: “Wij beschermen de vertrouwelijkheid, integriteit en beschikbaarheid van onze informatiesystemen en houden ons aan geldende wet- en regelgeving.”
• Security baseline: “Alle servers draaien een ondersteunde versie van het besturingssysteem, worden maandelijks gepatcht en loggen authenticatiegebeurtenissen naar een centrale SIEM.”

Een security policy zonder baseline blijft vaag en moeilijk te handhaven. Een baseline zonder policy mist de strategische inbedding en het bestuurlijk mandaat. De twee documenten versterken elkaar en vormen samen de ruggengraat van een volwassen beveiligingsprogramma.

Hoe weet je of je security baseline nog actueel is?

Je weet dat een security baseline actueel is als deze regelmatig wordt getoetst aan nieuwe dreigingen, gewijzigde wet- en regelgeving en veranderingen in de IT-omgeving van de organisatie. Een baseline die twee jaar geleden is opgesteld en sindsdien niet is herzien, is in de meeste gevallen verouderd.

Concrete signalen dat een herziening nodig is:

• Er zijn nieuwe technologieën of systemen in gebruik genomen die niet in de baseline zijn opgenomen
• Er heeft een beveiligingsincident plaatsgevonden dat heeft aangetoond dat de huidige maatregelen ontoereikend zijn
• Wet- en regelgeving is gewijzigd, zoals de inwerkingtreding van de Cyberbeveiligingswet (verwacht in 2026)
• Een externe audit of penetratietest heeft kwetsbaarheden blootgelegd die de baseline niet afdekt
• Het dreigingslandschap is veranderd, bijvoorbeeld door de opkomst van nieuwe aanvalstechnieken

Als goede praktijk geldt: beoordeel de baseline minimaal één keer per jaar formeel, en voer tussentijdse updates door na significante wijzigingen in de organisatie of het dreigingslandschap. Koppel dit beoordelingsmoment bij voorkeur aan de jaarlijkse risicoanalyse, zodat de baseline altijd aansluit op de actuele risico’s. Organisaties die gebruik maken van een virtuele CISO-dienst hebben een vaste sparringpartner die dit proces structureel bewaakt.

Hoe Q-Cyber helpt met het opstellen van een security baseline

Een goede security baseline opstellen klinkt overzichtelijk, maar vraagt in de praktijk om technische kennis, beleidsexpertise en een helder beeld van de risico’s die specifiek voor jouw organisatie gelden. Wij helpen organisaties bij elke stap van dit proces, van risicoanalyse tot implementatie en borging.

Wat wij concreet voor je doen:

• Gap-analyse: we brengen in kaart waar jouw huidige beveiliging afwijkt van een erkend normenkader zoals ISO 27002 of de BIO2
• Beleid op maat: we schrijven een security baseline die aansluit op jouw organisatie, sector en wettelijke verplichtingen, waaronder NIS2
• Technische toetsing: via vulnerability scans en penetratietests valideren we of de geïmplementeerde maatregelen daadwerkelijk werken
• Training en bewustwording: we verzorgen trainingen voor bestuurders en medewerkers zodat de baseline niet alleen op papier bestaat
• Continu beheer: via onze vCISO-dienst bewaken we proactief of jouw baseline actueel blijft en passen we deze aan bij nieuwe dreigingen of regelgeving

Wij werken onafhankelijk, zonder binding aan softwarepartijen, en geven altijd pragmatisch advies dat past bij de realiteit van jouw organisatie. Wil je weten waar jouw baseline nu staat en wat er nodig is om die op het gewenste niveau te brengen? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Veilig softwareontwikkeling: basisprincipes

Geplaatst op: 16 september 2026

Veilige softwareontwikkeling betekent dat beveiliging structureel is ingebouwd in elk onderdeel van het ontwikkelproces, van ontwerp tot deployment. De basisprincipes omvatten threat modeling, secure coding, geautomatiseerde beveiligingstests en continue monitoring. Dit geldt voor elk team dat software bouwt of beheert, ongeacht de omvang of sector. De vragen hieronder behandelen de meest essentiële aspecten van softwarebeveiliging in de praktijk.

Wat zijn de grootste beveiligingsrisico’s bij softwareontwikkeling?

De grootste beveiligingsrisico’s bij softwareontwikkeling zijn onveilige invoerverwerking, gebrekkig toegangsbeheer, blootstelling van gevoelige gegevens en het gebruik van kwetsbare afhankelijkheden. Deze risico’s komen terug in vrijwel elke applicatie en zijn verantwoordelijk voor het overgrote deel van succesvolle aanvallen op softwaresystemen.

De OWASP Top 10 is de meest gebruikte referentie voor veelvoorkomende kwetsbaarheden in webapplicaties. Denk aan SQL-injectie, waarbij een aanvaller via invoervelden directe toegang tot een database kan krijgen, of aan broken access control, waarbij gebruikers buiten hun eigen rechten kunnen handelen. Cross-site scripting (XSS) en onveilige deserialisatie zijn andere klassiekers die jaar na jaar terugkeren.

Naast de technische kwetsbaarheden is er een organisatorisch risico dat vaak onderschat wordt: het gebruik van verouderde of onbeheerde softwarecomponenten. Veel applicaties zijn opgebouwd uit open source bibliotheken. Als die bibliotheken niet actief worden bijgehouden, ontstaan er kwetsbaarheden in de toeleveringsketen, ook wel supply chain-risico’s genoemd. Aanvallers richten zich steeds vaker op deze zwakke schakels in plaats van op de applicatie zelf.

Een ander structureel risico is het ontbreken van beveiligingsvereisten in de beginfase van een project. Wanneer beveiliging pas laat in het ontwikkeltraject wordt meegenomen, zijn kwetsbaarheden al diep ingebakken in de architectuur en zijn ze kostbaar om te herstellen.

Wat is het verschil tussen security by design en security testing?

Security by design betekent dat beveiliging vanaf het eerste ontwerp wordt meegenomen als een fundamentele vereiste, niet als een toevoeging achteraf. Security testing is het achteraf controleren of een gebouwde applicatie kwetsbaarheden bevat. Beide zijn noodzakelijk, maar security by design voorkomt problemen terwijl security testing ze opspoort.

Bij security by design stelt een team al in de ontwerpfase vragen als: welke data verwerken we, wie heeft toegang tot welke functionaliteit en hoe gaan we om met authenticatie en autorisatie? Deze keuzes worden vastgelegd in de architectuur voordat er ook maar één regel code is geschreven. Het gevolg is dat beveiligingsmaatregelen organisch onderdeel worden van de applicatiestructuur.

Security testing, zoals een penetratietest, vindt plaats nadat software is gebouwd. Een tester of geautomatiseerd systeem probeert actief kwetsbaarheden te vinden door de applicatie aan te vallen op dezelfde manier als een kwaadwillende dat zou doen. Dit is waardevol, maar het heeft een beperking: als de architectuur fundamenteel onveilig is, kunnen tests symptomen blootleggen maar de oorzaak niet wegnemen.

De meest volwassen aanpak combineert beide: een stevige beveiligingsbasis door design, aangevuld met regelmatige tests om te verifiëren dat de implementatie ook in de praktijk werkt. Security by design zonder testing is zelfgenoegzaam. Security testing zonder design is dweilen met de kraan open.

Hoe werkt threat modeling in de praktijk?

Threat modeling is een gestructureerde methode waarbij een team systematisch nadenkt over wie een applicatie zou willen aanvallen, hoe dat zou kunnen gebeuren en welke schade dat zou veroorzaken. In de praktijk gebeurt dit tijdens de ontwerpfase, vaak aan de hand van een dataflowdiagram en een gestandaardiseerd raamwerk zoals STRIDE.

Een praktische threat modeling sessie volgt doorgaans vier stappen:

1. Modelleer het systeem: teken de architectuur uit, inclusief alle datastromen, componenten, gebruikers en externe systemen.
2. Identificeer bedreigingen: gebruik een raamwerk zoals STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) om systematisch bedreigingen per component te benoemen.
3. Beoordeel risico’s: weeg de kans en impact van elke bedreiging af om prioriteiten te stellen.
4. Bepaal tegenmaatregelen: koppel aan elke relevante bedreiging een concrete maatregel, of accepteer bewust een risico als de impact laag genoeg is.

Threat modeling hoeft niet ingewikkeld te zijn. Een whiteboard sessie van twee uur met het ontwikkelteam en een security specialist levert al aanzienlijk meer inzicht op dan geen sessie. Het doel is niet perfectie, maar bewustzijn: weet het team wat ze bouwen, voor wie en wat er mis kan gaan?

Threat modeling is ook een levend document. Wanneer de architectuur verandert, een nieuwe integratie wordt toegevoegd of een nieuwe gebruikersrol wordt geïntroduceerd, is het tijd om het model te herzien.

Welke secure coding-principes moet elk ontwikkelteam kennen?

Elk ontwikkelteam moet minimaal de volgende secure coding-principes beheersen: inputvalidatie, het principe van least privilege, veilig sessiebeheer, foutafhandeling zonder informatielekkage en het gebruik van bewezen cryptografische standaarden. Deze principes vormen de ruggengraat van basisprincipes softwarebeveiliging en zijn van toepassing ongeacht de gebruikte programmeertaal of het platform.

Input validatie en output encoding

Vertrouw nooit op invoer van een gebruiker of een extern systeem. Valideer altijd of invoer voldoet aan het verwachte formaat, type en bereik, en gebruik output encoding om te voorkomen dat data als uitvoerbare code wordt geïnterpreteerd. Dit is de primaire verdediging tegen injectie-aanvallen en cross-site scripting.

Least privilege en veilig sessiebeheer

Elke component, gebruiker en service mag alleen toegang hebben tot wat strikt noodzakelijk is voor zijn functie. Dit beperkt de schade als een onderdeel wordt gecompromitteerd. Combineer dit met veilig sessiebeheer: gebruik korte sessietijden, veilige cookies met de juiste attributen en invalideer sessies direct na uitloggen of na een wachtwoordwijziging.

Twee andere principes die elk team moet internaliseren: foutmeldingen mogen nooit technische details bevatten die een aanvaller helpen, en cryptografie moet altijd gebaseerd zijn op actuele, gestandaardiseerde algoritmen. Zelf cryptografie implementeren is een veelgemaakte fout die bijna altijd tot kwetsbaarheden leidt.

Wanneer moet een organisatie een penetratietest laten uitvoeren?

Een organisatie moet een penetratietest laten uitvoeren bij de lancering van een nieuwe applicatie, na significante architectuurwijzigingen, bij de verwerking van gevoelige of persoonsgebonden data en als onderdeel van een jaarlijkse beveiligingscyclus. Voor organisaties die onder regelgeving zoals NIS2 vallen, is periodieke penetratietesting bovendien een verwachte maatregel binnen de zorgplicht.

Naast deze vaste momenten zijn er specifieke situaties die een directe aanleiding vormen voor een test:

• Na een beveiligingsincident, om te achterhalen hoe de aanvaller is binnengekomen en of er nog andere kwetsbaarheden bestaan.
• Voorafgaand aan een audit of certificering, zoals ISO 27001 of een NIS2-compliance check.
• Bij de integratie van een overgenomen applicatie of systeem waarvan de beveiligingsstatus onbekend is.
• Wanneer een derde partij toegang krijgt tot kritieke systemen via een nieuwe koppeling of API.

Een penetratietest simuleert een echte aanval op een gecontroleerde manier. De tester probeert actief in te breken, rapporteert wat er is gevonden en geeft advies over herstel. De waarde zit niet alleen in de gevonden kwetsbaarheden, maar ook in het inzicht dat een externe, onbevooroordeelde blik oplevert over de werkelijke staat van de beveiliging. Meer informatie over wat een dergelijke test inhoudt, vind je op de pagina over pentesten.

Hoe integreer je beveiliging in een CI/CD-pipeline?

Beveiliging integreer je in een CI/CD-pipeline door geautomatiseerde beveiligingscontroles toe te voegen als verplichte stappen in het buildproces. Dit omvat statische code-analyse (SAST), controle op kwetsbare afhankelijkheden (SCA) en dynamische tests (DAST) die draaien als onderdeel van elke deploymentcyclus. Dit principe staat bekend als DevSecOps.

De meest effectieve integratie volgt een gelaagde aanpak:

• Bij elke commit: voer een statische analyse uit die de broncode controleert op bekende kwetsbare patronen, zoals hardcoded wachtwoorden of onveilige functies.
• Bij elke build: controleer automatisch of gebruikte bibliotheken en afhankelijkheden bekende kwetsbaarheden bevatten via tools zoals Dependabot of Snyk.
• Bij deployment naar een testomgeving: voer dynamische tests uit die de draaiende applicatie aanvallen op veelvoorkomende kwetsbaarheden.
• Voor productie: voer een handmatige review uit van beveiligingsgevoelige wijzigingen en zorg dat secrets nooit in de codebase terechtkomen via secrets scanning.

Een veelgemaakte fout is het toevoegen van te veel beveiligingstools tegelijk, waardoor de pipeline traag wordt en ontwikkelaars meldingen gaan negeren. Begin met een beperkte set van hoge-waarde controles, stel drempelwaarden in die daadwerkelijk de build laten falen bij kritieke bevindingen en bouw van daaruit verder. Beveiliging in de pipeline werkt alleen als het team de resultaten serieus neemt en er actief op handelt.

Voor organisaties die willen weten hoe hun huidige beveiligingspraktijk zich verhoudt tot de eisen van relevante wet- en regelgeving, biedt de pagina over cybersecurity regelgeving een goed startpunt.

Hoe Q-Cyber helpt met veilige softwareontwikkeling

Veilige softwareontwikkeling is geen eenmalig project, maar een doorlopend proces dat technische kennis, beleid en bewustzijn combineert. Q-Cyber ondersteunt organisaties bij het opbouwen van die capaciteit, van de eerste risicoanalyse tot de implementatie van concrete maatregelen. Onze aanpak is pragmatisch en onafhankelijk: we zijn niet gebonden aan softwarepartijen en adviseren wat werkelijk past bij jouw organisatie en risicoprofiel.

Wat we concreet bieden op het gebied van softwarebeveiliging:

• Penetratietesten en vulnerability scans om kwetsbaarheden in applicaties en infrastructuur bloot te leggen voordat aanvallers dat doen.
• Secure development advies inclusief threat modeling sessies en begeleiding bij het opzetten van een DevSecOps aanpak.
• Beleidsvorming en NIS2-begeleiding voor organisaties die moeten aantonen dat softwarebeveiliging structureel is geborgd in processen en governance.
• Trainingen en bewustwording voor ontwikkelteams en bestuurders, zodat beveiliging niet alleen op papier staat maar ook in de praktijk wordt toegepast.
• Virtuele CISO-diensten via ons Continuous-Q programma, waarbij een team van specialisten structureel meekijkt en adviseert.

Wil je weten waar jouw organisatie nu staat en welke stappen het meeste impact hebben? Neem contact op en we denken graag met je mee.

Lees meer

Wat is applicatiebeveiliging en waarom is het belangrijk?

Geplaatst op: 15 september 2026

Applicatiebeveiliging is het geheel van maatregelen, processen en technieken waarmee software en applicaties worden beschermd tegen ongeautoriseerde toegang, aanvallen en datalekken. Het is een essentieel onderdeel van elke cybersecuritystrategie, omdat applicaties direct in contact staan met gebruikers, klanten en gevoelige bedrijfsdata. In dit artikel beantwoorden we de meest gestelde vragen over app security: van de risico’s en kwetsbaarheden tot praktische tests en het juiste moment om te beginnen.

Welke risico’s ontstaan er zonder applicatiebeveiliging?

Zonder applicatiebeveiliging lopen organisaties het risico dat aanvallers via kwetsbare software toegang krijgen tot systemen, klantgegevens stelen, processen verstoren of ransomware installeren. Applicaties zijn een van de meest aangevallen ingangspunten voor cybercriminelen, juist omdat ze vaak direct verbonden zijn met databases en bedrijfskritische informatie.

De gevolgen van een succesvolle aanval via een onbeveiligde applicatie zijn breed. Denk aan datalekken waarbij persoonsgegevens van klanten op straat belanden, financiële schade door bedrijfsonderbreking, reputatieschade en juridische aansprakelijkheid. Onder wetgeving zoals de NIS2-richtlijn kunnen organisaties bovendien forse boetes verwachten als zij onvoldoende maatregelen hebben genomen om hun systemen te beveiligen.

Naast directe schade zijn er ook indirecte risico’s. Een gecompromitteerde applicatie kan als springplank dienen naar andere systemen binnen het netwerk, waardoor een aanvaller zich steeds verder kan bewegen door de infrastructuur. Dit maakt softwarebeveiliging niet alleen een technisch vraagstuk, maar ook een bedrijfsrisico dat aandacht verdient op bestuursniveau.

Hoe werkt applicatiebeveiliging in de praktijk?

Applicatiebeveiliging werkt door op meerdere niveaus beveiligingsmaatregelen in te bouwen: tijdens het ontwerp en de ontwikkeling van software, bij de uitrol en het beheer, en door continue monitoring en testing achteraf. Het is geen eenmalige actie, maar een doorlopend proces dat meegroeit met de applicatie en het dreigingslandschap.

In de praktijk betekent dit dat beveiliging al vroeg in de softwareontwikkeling wordt meegenomen, een aanpak die ook wel “security by design” wordt genoemd. Ontwikkelaars schrijven code volgens veilige standaarden, voeren code reviews uit en gebruiken geautomatiseerde tools om kwetsbaarheden te detecteren voordat software live gaat.

Na de livegang is continue aandacht nodig. Applicaties worden regelmatig getest op nieuwe kwetsbaarheden, software-updates worden tijdig doorgevoerd en toegangsrechten worden strak beheerd. Authenticatiemechanismen zoals multi-factorauthenticatie zorgen ervoor dat alleen bevoegde gebruikers toegang krijgen. Logging en monitoring maken het mogelijk om verdacht gedrag vroegtijdig te signaleren en snel te reageren op incidenten.

Wat zijn de meest voorkomende kwetsbaarheden in applicaties?

De meest voorkomende kwetsbaarheden in applicaties zijn SQL-injectie, cross-site scripting (XSS), onveilige authenticatie, verkeerde configuraties en het gebruik van verouderde of kwetsbare softwarecomponenten. Deze zwakke plekken komen voor in zowel maatwerksoftware als standaardapplicaties en vormen de basis van het overgrote deel van succesvolle aanvallen.

Een overzicht van veelvoorkomende kwetsbaarheden:

• SQL-injectie: aanvallers manipuleren databasequery’s via invoervelden om ongeautoriseerde toegang te krijgen tot gegevens.
• Cross-site scripting (XSS): kwaadaardige scripts worden geïnjecteerd in webpagina’s die vervolgens worden uitgevoerd in de browser van andere gebruikers.
• Onveilige authenticatie: zwak wachtwoordbeleid, ontbrekende meerfactorauthenticatie of slecht beheerde sessies geven aanvallers eenvoudig toegang.
• Verkeerde configuraties: standaardinstellingen, open poorten of te ruime toegangsrechten creëren onnodige aanvalsoppervlakken.
• Verouderde componenten: softwarebibliotheken of frameworks met bekende kwetsbaarheden die niet tijdig zijn bijgewerkt.
• Onvoldoende encryptie: gevoelige data die onversleuteld wordt opgeslagen of verstuurd, is kwetsbaar voor onderschepping.

De OWASP Top 10 is een veelgebruikte referentie binnen de wereld van cybersecurityapplicaties. Deze lijst beschrijft de tien meest kritieke beveiligingsrisico’s voor webapplicaties en wordt regelmatig bijgewerkt op basis van actuele dreigingsinformatie. Het is een nuttig startpunt voor elke organisatie die de beveiliging van haar software serieus neemt.

Wanneer moet een organisatie beginnen met applicatiebeveiliging?

Een organisatie moet beginnen met applicatiebeveiliging op het moment dat software wordt ontwikkeld of aangeschaft, en niet pas nadat een applicatie al live is. Hoe eerder beveiliging wordt meegenomen in het proces, hoe goedkoper en effectiever het is om kwetsbaarheden te verhelpen.

Beveiligingsproblemen die vroeg in de ontwikkeling worden ontdekt, zijn aanzienlijk eenvoudiger en goedkoper op te lossen dan problemen die pas na de livegang aan het licht komen. Dit principe staat bekend als “shift left”: beveiliging verschuift naar het begin van de ontwikkelcyclus in plaats van als nagedachte aan het einde toe te voegen.

Voor organisaties die al bestaande applicaties in gebruik hebben zonder formeel beveiligingsbeleid, is het antwoord simpel: nu beginnen. Elke dag zonder adequate app security is een dag waarop risico’s onnodig groot zijn. Een eerste stap kan een penetratietest zijn om inzicht te krijgen in de huidige staat van beveiliging, gevolgd door een gestructureerd plan om kwetsbaarheden te verhelpen en processen te verbeteren.

Wat is het verschil tussen applicatiebeveiliging en netwerkbeveiliging?

Applicatiebeveiliging richt zich op het beveiligen van software en de data die applicaties verwerken, terwijl netwerkbeveiliging zich richt op de bescherming van de infrastructuur waarmee systemen met elkaar communiceren. Beide zijn noodzakelijk, maar ze beschermen tegen verschillende soorten aanvallen op verschillende niveaus.

Netwerkbeveiliging omvat maatregelen zoals firewalls, intrusion detection systems en VPN-verbindingen. Het doel is om ongeautoriseerd verkeer buiten de deur te houden en de communicatie tussen systemen te beveiligen. Netwerkbeveiliging beschermt de “snelwegen” waarover data reist.

Applicatiebeveiliging gaat een laag dieper. Een aanvaller die via een legitieme verbinding een applicatie bereikt, wordt door netwerkbeveiliging niet tegengehouden. Pas als de applicatie zelf goed beveiligd is, worden aanvallen zoals SQL-injectie of XSS geblokkeerd. Beide vormen van beveiliging vullen elkaar aan en zijn samen onderdeel van een gelaagde cybersecurityaanpak. Wie alleen op netwerkbeveiliging vertrouwt, laat een groot deel van het aanvalsoppervlak onbeschermd.

Hoe test je de beveiliging van een applicatie?

De beveiliging van een applicatie test je door een combinatie van geautomatiseerde scans, handmatige code reviews en penetratietests uit te voeren. Elke methode heeft zijn eigen sterktes en samen geven ze een compleet beeld van de kwetsbaarheden in een applicatie.

Geautomatiseerde scans

Geautomatiseerde tools scannen de broncode of de lopende applicatie op bekende kwetsbaarheden. Static Application Security Testing (SAST) analyseert de code zonder de applicatie uit te voeren, terwijl Dynamic Application Security Testing (DAST) de applicatie test terwijl deze actief is. Deze tools zijn snel en schaalbaar, maar missen soms de nuance die menselijke testers wel oppikken.

Penetratietests en ethisch hacken

Bij een penetratietest simuleert een ethische hacker een echte aanval op de applicatie. De tester probeert actief kwetsbaarheden te misbruiken om te bepalen hoe ver een aanvaller zou kunnen komen. Dit geeft een realistisch beeld van de werkelijke beveiligingsstatus en brengt kwetsbaarheden aan het licht die geautomatiseerde tools missen. Een red team gaat nog een stap verder door een volledige aanvalssimulatie uit te voeren, inclusief social engineering en andere geavanceerde technieken.

Naast technische tests is ook het beoordelen van het beveiligingsbeleid rondom applicaties waardevol. Zijn toegangsrechten goed ingericht? Worden updates tijdig uitgerold? Is er een procedure voor het melden en afhandelen van kwetsbaarheden? Technische tests en beleidsmatige beoordeling samen geven de meest volledige blik op de staat van applicatiebeveiliging binnen een organisatie.

Hoe Q-Cyber helpt met applicatiebeveiliging

Wij begrijpen dat applicatiebeveiliging voor veel organisaties complex en overweldigend kan aanvoelen. Toch is het een van de meest concrete stappen die een organisatie kan zetten om haar digitale weerbaarheid te vergroten. Q-Cyber helpt organisaties van elke omvang om grip te krijgen op hun softwarebeveiliging, zonder onnodige complexiteit of binding aan softwarepartijen.

Wat wij voor uw organisatie kunnen doen:

• Penetratietests en vulnerability scans: wij testen uw applicaties op kwetsbaarheden met een combinatie van geautomatiseerde tools en handmatige expertise, inclusief ethisch hacken door ons red team.
• Beleidsvorming en advies: wij schrijven concreet beveiligingsbeleid rondom applicatieontwikkeling en -beheer, afgestemd op uw organisatie en eventuele NIS2-verplichtingen.
• Virtuele CISO via Continuous-Q: via ons Continuous-Q programma bieden wij doorlopende begeleiding door een team van specialisten, zodat applicatiebeveiliging structureel is ingebed in uw organisatie.
• Trainingen en bewustwording: wij verzorgen trainingen voor ontwikkelaars, beheerders en bestuurders zodat iedereen begrijpt welke rol zij spelen in de beveiliging van applicaties.
• Onafhankelijk advies: wij werken zonder binding aan softwarepartijen en geven altijd pragmatisch, eerlijk advies dat past bij uw situatie.

Wacht niet tot een incident u dwingt om in actie te komen. Neem contact op met Q-Cyber en ontdek hoe wij uw organisatie kunnen helpen om applicatiebeveiliging structureel en effectief aan te pakken.

Lees meer

Hoe weet je of een pentest daadwerkelijk handmatig is uitgevoerd?

Geplaatst op: 15 september 2026

Je hebt een pentest laten uitvoeren en het rapport ligt op tafel. Maar hoe weet je of die test daadwerkelijk handmatig is uitgevoerd door een ervaren ethical hacker, of dat je in werkelijkheid betaalt voor een geautomatiseerde scan met een duur logo erop? Het onderscheid is cruciaal. Een handmatige pentest ontdekt aanvalspaden die geautomatiseerde tools structureel missen. Een geautomatiseerde scan doet dat niet, maar presenteert zich soms wel als volwaardige penetratietest.

In deze gids leer je stap voor stap hoe je de kwaliteit van een pentest verifieert: van het beoordelen van het rapport tot het stellen van de juiste vragen en het herkennen van rode vlaggen. Zo weet je zeker dat je investering daadwerkelijk waarde heeft opgeleverd.

Wat een echt handmatige pentest onderscheidt van een geautomatiseerde scan

Begrijp eerst het fundamentele verschil voordat je een rapport beoordeelt of vragen stelt. Een geautomatiseerde vulnerability scan werkt op basis van bekende CVE-databases en vergelijkt je omgeving met een lijst van bekende zwakheden. Dat is nuttig voor basishygiëne, maar het stopt daar ook. Een echte handmatige pentest gaat aanzienlijk verder en werkt op drie lagen:

• Laag 1 – Bekende kwetsbaarheden: Bekende CVE’s, publieke exploits en controle of patches correct zijn uitgevoerd. Dit is wat een geautomatiseerde scan ook kan.
• Laag 2 – Individuele zwakheden: Verkeerde Azure-configuraties, te ruime permissies, identity weaknesses en onveilige applicatie-instellingen. Deels automatiseerbaar, maar vereist menselijk oordeel.
• Laag 3 – Gecorreleerde aanvalspaden: Hier voegt een handmatige penetratietest echte waarde toe. Een ethical hacker onderzoekt wat er gebeurt als meerdere kleine zwaktes worden gecombineerd. Denk aan een keten als SSRF naar managed identity naar Azure RBAC naar Key Vault naar subscription owner. Los van elkaar lijkt geen enkele bevinding kritiek. Samen leiden ze tot volledige toegang tot cloudresources.

Het kernprincipe dat je moet onthouden: aanvallers zien geen losse bevindingen, zij zien aanvalspaden. Een geautomatiseerde scan rapporteert bevindingen. Een handmatige pentest reconstrueert aanvalspaden. Als je rapport alleen een lijst van CVE’s bevat zonder narratief over hoe een aanvaller ze zou combineren, is dat een sterke aanwijzing dat er weinig handmatig werk aan te pas is gekomen.

Beoordeel het rapport op tekenen van handmatig werk

Open het rapport en analyseer het op structuur en inhoud. Een kwalitatief handmatig pentestrapport heeft herkenbare kenmerken die je kunt controleren zonder zelf technisch expert te zijn.

1. Controleer de executive summary: Bevat die een verhaallijn over hoe een aanvaller te werk zou gaan, of is het een samenvatting van aantallen gevonden kwetsbaarheden? Een handmatig rapport vertelt een aanvalsverhaal.
2. Zoek naar omgevingsspecifieke details: Staan er screenshots, commando’s of outputs in die specifiek zijn voor jouw systemen, jouw domeinnamen, jouw applicatiestructuur? Generieke beschrijvingen zonder bewijs zijn een waarschuwingssignaal.
3. Beoordeel de bevindingen op diepgang: Een handmatige bevinding beschrijft de exploitatiestap, het bewijs van uitvoering en de specifieke impact voor jouw organisatie. Een geautomatiseerde bevinding kopieert de CVE-beschrijving en plakt daar een CVSS-score bij.
4. Let op attack path-analyse: Worden bevindingen in verband gebracht met elkaar? Staat er beschreven hoe een aanvaller bevinding A gebruikt als opstap naar bevinding B? Zo niet, dan ontbreekt de meest waardevolle laag van handmatig pentestwerk.
5. Tel de low-severitybevindingen: Paradoxaal genoeg is een rapport zonder low-severitybevindingen soms een slecht teken. Handmatige testers ontdekken ook kleine misconfiguraties die geautomatiseerde tools overslaan, juist omdat die in een aanvalsketen gevaarlijk kunnen zijn.

Verwacht je na deze analyse een rapport dat concreet is, omgevingsspecifiek en opgebouwd als een aanvalsverhaal? Dan is de kans groot dat er daadwerkelijk handmatig werk is verricht. Ontbreekt die diepgang, dan is het tijd om vragen te stellen.

Stel de juiste vragen aan je pentestprovider

Met je rapport als uitgangspunt ga je het gesprek aan met de pentestprovider. De antwoorden op onderstaande vragen onthullen snel of je met een echte handmatige test te maken hebt gehad. Stel deze vragen bij voorkeur vóór je een nieuwe opdracht plaatst, maar ze zijn ook waardevol als evaluatiegesprek achteraf.

1. Welke tools hebben jullie gebruikt en wat hebben jullie handmatig gedaan? Een eerlijke provider benoemt beide. Elke serieuze pentest combineert geautomatiseerde tools voor verkenning met handmatige analyse voor exploitatie en attack path-reconstructie. Een antwoord als “wij doen alles handmatig” of “wij gebruiken alleen tools” is allebei een rode vlag.
2. Hoeveel uur heeft de tester actief in mijn omgeving doorgebracht? Een volwaardige handmatige pentest van een gemiddeld netwerk of applicatie kost meerdere dagen. Als het antwoord enkele uren is voor een complexe omgeving, kloppen de getallen niet.
3. Kun je uitleggen hoe bevinding X en bevinding Y samen een aanvalsketen vormen? Kies twee bevindingen uit je rapport en vraag dit concreet. Een handmatige tester kan dit direct beantwoorden. Iemand die een scan heeft gedraaid, kan dat niet.
4. Welke bevindingen hebben jullie handmatig gevalideerd en hoe? Geautomatiseerde tools produceren false positives. Handmatige testers valideren elke bevinding. Vraag naar het validatieproces.
5. Welke certificeringen hebben de testers die mijn omgeving hebben getest? Denk aan OSCP, CEH of vergelijkbare offensieve certificeringen. Vraag specifiek wie de test heeft uitgevoerd, niet welke certificeringen het bedrijf in algemene zin bezit.

Na dit gesprek heb je een helder beeld van de werkwijze achter je rapport. Zijn de antwoorden vaag, defensief of inconsistent met wat er in het rapport staat, dan is verdere technische validatie aan te raden.

Valideer de bevindingen technisch na afloop

Als je intern technische capaciteit hebt, of toegang tot een onafhankelijke partij, kun je een steekproef van de bevindingen zelf valideren. Dit hoeft geen volledige hertest te zijn. Een gerichte validatie van drie tot vijf bevindingen geeft al veel inzicht in de betrouwbaarheid van het volledige rapport.

1. Selecteer een mix van bevindingen: Kies minimaal één high-severity en één low-severitybevinding. Zo test je zowel de kwaliteit van de kritieke als de minder urgente rapportage.
2. Controleer of de bevinding reproduceerbaar is: Kan je eigen team of een tweede partij de bevinding bevestigen op basis van de beschrijving in het rapport? Een goede handmatige bevinding bevat genoeg detail om reproduceerbaar te zijn.
3. Vergelijk de bevindingen met een geautomatiseerde scan: Voer zelf een gratis of goedkope vulnerability scan uit op hetzelfde scope. Staan alle bevindingen uit het pentestrapport ook in de geautomatiseerde scan, en staan er geen bevindingen in het rapport die alleen een handmatige tester had kunnen vinden? Dan is er reden tot twijfel. Een handmatige pentest zou bevindingen moeten bevatten die een geautomatiseerde scan mist.
4. Beoordeel de aanbevelingen op specificiteit: Generieke aanbevelingen zoals “update uw software” of “implementeer sterker wachtwoordbeleid” wijzen op geautomatiseerde output. Handmatige aanbevelingen zijn specifiek voor jouw architectuur en configuratie.

Na deze technische validatie weet je of de bevindingen standhouden. Als meerdere bevindingen niet reproduceerbaar zijn of als alle bevindingen ook door een geautomatiseerde scan worden gevonden, heb je sterke aanwijzingen dat de pentest niet de diepgang had die je betaald hebt.

Herken rode vlaggen bij twijfelachtige pentestleveranciers

Sommige signalen zijn al zichtbaar voordat je het rapport ontvangt. Leer deze rode vlaggen herkennen zodat je ze in een volgende selectieronde kunt vermijden. Zie ook de achtergrond bij offensieve security voor meer context over hoe kwalitatief pentestwerk eruitziet.

• Een onrealistisch lage prijs: Een handmatige pentest kost tijd van gekwalificeerde professionals. Als de prijs te laag is om meerdere dagen menselijk werk te dekken, is de kans groot dat er vooral tools draaien.
• Een te snel opgeleverd rapport: Een volwaardige handmatige pentest duurt meerdere dagen tot weken, afhankelijk van de scope. Een rapport dat binnen 24 uur na de startdatum wordt opgeleverd, is vrijwel zeker geautomatiseerd.
• Geen kickoff of scopegesprek: Handmatige testers willen begrijpen wat ze testen en waarom. Een provider die geen vragen stelt over je architectuur, dreigingsmodel of kritieke assets, test waarschijnlijk niet handmatig.
• Geen mogelijkheid tot toelichting: Een serieuze pentestpartij staat achter haar bevindingen en kan die mondeling toelichten. Als een provider weigert of niet in staat is om bevindingen te verduidelijken, is dat een ernstig signaal.
• Rapport bevat alleen CVSS-scores zonder context: CVSS-scores zijn nuttig, maar een handmatige pentest vertaalt die naar de specifieke impact voor jouw organisatie. Alleen scores zonder contextuele duiding wijzen op geautomatiseerde output.
• Geen aandacht voor aanvalspaden: Als het rapport geen enkele verwijzing bevat naar hoe bevindingen gecombineerd kunnen worden, ontbreekt de meest waardevolle dimensie van handmatig pentestwerk.

Met deze rode vlaggen in gedachten ben je beter uitgerust om leveranciers te beoordelen voordat je een opdracht plaatst. Zo voorkom je dat je budget gaat naar een geautomatiseerde scan die zich voordoet als een handmatige penetratietest. Voor organisaties die twijfelen over hun huidige testprogramma kan ook red teaming een waardevolle aanvulling zijn om te toetsen of een aanvaller daadwerkelijk door de verdediging heen kan breken.

Hoe Q-Cyber helpt bij het kiezen van een betrouwbare pentest

Bij Q-Cyber begrijpen we dat de markt voor penetratietesten onoverzichtelijk is. Leveranciers die geautomatiseerde scans verkopen als handmatige pentests ondermijnen het vertrouwen in de hele sector en laten organisaties met een vals gevoel van veiligheid achter. Onze aanpak is daarom gebouwd op transparantie en technische diepgang.

• Volledig handmatig uitgevoerd: Onze ethical hackers werken zoals echte aanvallers, inclusief creatieve technieken die nog niet in standaard beveiligingsplaybooks staan.
• Attack path-rapportage: We rapporteren niet alleen losse bevindingen, maar reconstrueren hoe een aanvaller meerdere zwakheden combineert tot een volledige aanvalsketen.
• Omgevingsspecifiek en concreet: Elke bevinding is voorzien van bewijs, reproductiestappen en een aanbeveling die past bij jouw specifieke architectuur.
• Onafhankelijk advies: We zijn niet gebonden aan softwarepartijen of toeleveranciers, waardoor ons advies altijd in jouw belang is.
• Optioneel: continu testen via Continuous-Q®: Voor organisaties die verder willen gaan dan een jaarlijkse momentopname bieden we een programma waarbij testen een doorlopend proces wordt in plaats van een eenmalige meting.

Wil je zeker weten dat je volgende pentest daadwerkelijk handmatig en kwalitatief is? Neem contact op en we denken graag met je mee over de juiste aanpak voor jouw organisatie.

Lees meer

Hoe beveilig je mobiele apparaten van medewerkers?

Geplaatst op: 14 september 2026

Mobiele apparaten van medewerkers beveilig je door een combinatie van technisch beleid, beheeroplossingen en gebruikersbewustzijn. Denk aan Mobile Device Management (MDM), sterke authenticatie, encryptie en een duidelijk BYOD-beleid. Deze maatregelen gelden voor elk apparaat dat toegang heeft tot bedrijfsdata, ongeacht of het eigendom is van de medewerker of de organisatie. In dit artikel beantwoorden we de meest gestelde vragen over mobiele beveiliging voor bedrijven.

Welke risico’s brengen mobiele apparaten van medewerkers met zich mee?

Mobiele apparaten van medewerkers vormen een van de meest kwetsbare toegangspunten in een bedrijfsnetwerk. Ze worden gebruikt op onbeveiligde wifi-netwerken, raken kwijt of worden gestolen, en draaien vaak verouderde software. Elk van deze situaties kan leiden tot ongeautoriseerde toegang tot bedrijfsdata of systemen.

De risico’s zijn concreet en divers. Een verloren smartphone met toegang tot bedrijfse-mail is een direct datalek. Een medewerker die verbinding maakt via een openbaar wifinetwerk in een café is kwetsbaar voor een man-in-the-middle-aanval. En een privéapparaat waarop ook zakelijke apps staan, maar dat nooit een beveiligingsupdate heeft ontvangen, is een open deur voor aanvallers.

De meest voorkomende risico’s op een rij:

• Verlies of diefstal van het apparaat, met directe toegang tot bedrijfsdata als gevolg
• Onbeveiligde netwerken zoals openbare wifi waarbij dataverkeer kan worden onderschept
• Verouderde software en apps met bekende kwetsbaarheden die niet zijn gepatcht
• Phishing via sms of messaging-apps, ook wel smishing genoemd
• Ongecontroleerde app-installaties die malware of spyware kunnen bevatten
• Zwakke of hergebruikte wachtwoorden zonder multi-factor authenticatie

Wat dit extra complex maakt, is dat medewerkers mobiele apparaten gebruiken buiten de traditionele beveiligingsperimeter van het kantoornetwerk. De grenzen van het bedrijfsnetwerk zijn daarmee in de praktijk verdwenen, en geldende regelgeving zoals NIS2 vraagt organisaties expliciet om ook deze risico’s te adresseren als onderdeel van hun zorgplicht.

Wat is Mobile Device Management en hoe werkt het?

Mobile Device Management (MDM) is een beheersysteem waarmee organisaties mobiele apparaten centraal kunnen beheren, beveiligen en monitoren. Via een MDM-platform kunnen IT-beheerders op afstand beleid afdwingen, apps installeren of verwijderen, en apparaten wissen als ze verloren of gestolen zijn. MDM werkt via een agent die op het apparaat wordt geïnstalleerd en verbinding maakt met een centrale beheerconsole.

Een MDM-oplossing geeft organisaties zichtbaarheid en controle over elk apparaat dat toegang heeft tot bedrijfssystemen. Zodra een apparaat is ingeschreven, kan de IT-afdeling onder andere:

• Verplichte schermvergrendeling en encryptie instellen
• Zakelijke en privédata van elkaar scheiden via een zogenaamde container
• Apparaten op afstand blokkeren of wissen bij verlies of diefstal
• App-gebruik beperken tot een goedgekeurde lijst
• Beveiligingsupdates automatisch uitrollen
• Naleving van beveiligingsbeleid monitoren en rapporteren

Moderne MDM-platforms, ook wel Unified Endpoint Management (UEM) genoemd, ondersteunen niet alleen smartphones en tablets maar ook laptops en andere eindpunten. Bekende oplossingen zijn Microsoft Intune, Jamf en VMware Workspace ONE. De keuze voor een specifiek platform hangt af van de bestaande IT-infrastructuur, het besturingssysteem van de apparaten en de gewenste beheerfunctionaliteit.

Belangrijk om te weten: MDM is geen wondermiddel. Het biedt controle over apparaatinstellingen, maar vervangt niet het bewustzijn van medewerkers of een breder beveiligingsbeleid. Het is een technische laag binnen een bredere aanpak van mobiele beveiliging voor bedrijven.

Wat is het verschil tussen BYOD, COPE en CYOD?

BYOD, COPE en CYOD zijn drie modellen voor het gebruik van mobiele apparaten op de werkvloer, en ze verschillen in wie het apparaat bezit en wie de controle heeft. BYOD staat voor Bring Your Own Device (privéapparaat, zakelijk gebruik), COPE voor Corporate Owned, Personally Enabled (zakelijk apparaat, ook privégebruik toegestaan), en CYOD voor Choose Your Own Device (medewerker kiest uit een goedgekeurde lijst, bedrijf is eigenaar).

BYOD: flexibel maar risicovol

Bij BYOD brengen medewerkers hun eigen smartphone of tablet mee en gebruiken die ook voor werk. Dit is populair vanwege het gebruiksgemak en de kostenbesparing, maar het stelt hoge eisen aan het beveiligingsbeleid. Het bedrijf heeft beperkte controle over het apparaat zelf. Een goede BYOD-aanpak vereist minimaal een MDM-oplossing met containerisatie, zodat zakelijke en privédata strikt gescheiden blijven.

COPE: controle met gebruiksgemak

Bij COPE koopt de organisatie de apparaten aan en beheert ze volledig, maar medewerkers mogen ze ook privé gebruiken. Dit geeft de IT-afdeling maximale controle over beveiliging en configuratie, terwijl medewerkers toch één apparaat voor alles kunnen gebruiken. COPE is doorgaans de veiligste optie, maar brengt hogere kosten met zich mee en vraagt om duidelijke afspraken over privacygebruik.

CYOD: balans tussen keuze en controle

CYOD combineert elementen van beide modellen. De medewerker kiest een apparaat uit een door de organisatie goedgekeurde selectie. Het bedrijf blijft eigenaar en beheert het apparaat, maar de medewerker heeft enige keuzevrijheid. Dit model werkt goed voor organisaties die standaardisatie willen zonder de gebruikerstevredenheid te schaden.

Welk model het beste past, hangt af van de omvang van de organisatie, het risicoprofiel en de mate van controle die nodig is. In sectoren met strenge compliance-eisen, zoals zorg of financiën, verdient COPE of CYOD de voorkeur boven BYOD.

Welke maatregelen zijn het meest effectief voor mobiele beveiliging?

De meest effectieve maatregelen voor de beveiliging van smartphones van medewerkers combineren technische controles met duidelijk beleid en bewustwording. Geen enkele maatregel staat op zichzelf: beveiliging werkt als een gelaagd systeem waarbij meerdere lagen samen de kans op een incident verkleinen.

De maatregelen met de grootste impact:

1. Multi-factor authenticatie (MFA) voor toegang tot zakelijke apps en systemen. Dit is een van de meest genoemde minimummaatregelen onder NIS2 en voorkomt dat een gestolen wachtwoord direct leidt tot een inbraak.
2. Encryptie van de opgeslagen data op het apparaat, zodat informatie onleesbaar is bij verlies of diefstal.
3. MDM met remote wipe, zodat apparaten op afstand gewist kunnen worden als ze kwijtraken.
4. Automatische schermvergrendeling na korte inactiviteit, gecombineerd met een sterke pincode of biometrische beveiliging.
5. Scheiding van zakelijke en privédata via containerisatie, met name bij BYOD-omgevingen.
6. Regelmatige software-updates en patchbeheer, bij voorkeur automatisch afgedwongen via MDM.
7. Bewustwordingstraining voor medewerkers, gericht op herkenning van phishing, smishing en social engineering.
8. VPN-gebruik bij verbinding via onbekende of openbare netwerken.

De combinatie van technische maatregelen en menselijk bewustzijn is doorslaggevend. Technologie kan veel afdwingen, maar een medewerker die een phishinglink aanklikt op zijn telefoon omzeilt elke technische barrière als er geen bewustzijn is.

Hoe stel je een mobiel beveiligingsbeleid op voor je organisatie?

Een mobiel beveiligingsbeleid stel je op door te beginnen met een inventarisatie van alle apparaten en gebruiksscenario’s, gevolgd door het vastleggen van regels voor toegang, gebruik en incidentrespons. Het beleid moet aansluiten op het risicoprofiel van de organisatie en begrijpelijk zijn voor medewerkers, niet alleen voor de IT-afdeling.

Een praktisch stappenplan:

1. Inventariseer welke apparaten toegang hebben tot bedrijfsdata en welk model van toepassing is (BYOD, COPE of CYOD).
2. Bepaal het risiconiveau per type data en gebruiker. Niet elk apparaat heeft toegang tot dezelfde informatie nodig.
3. Definieer minimumvereisten voor apparaten die toegang mogen krijgen, zoals een minimale OS-versie, verplichte encryptie en MFA.
4. Leg verantwoordelijkheden vast: waar is de organisatie verantwoordelijk voor, en wat wordt van de medewerker verwacht?
5. Beschrijf de procedure bij verlies of diefstal, inclusief meldplicht en de stappen die de IT-afdeling neemt.
6. Communiceer het beleid actief aan medewerkers en zorg voor een begrijpelijke samenvatting naast het volledige document.
7. Evalueer en actualiseer het beleid minimaal jaarlijks, of na een significant incident.

Een goed beleid is niet alleen een document, maar een levend kader dat medewerkers begrijpen en naleven. Koppel het beleid aan concrete trainingen en maak duidelijk wat de gevolgen zijn van niet-naleving. Voor organisaties die onder NIS2-regelgeving vallen, is een gedocumenteerd beveiligingsbeleid voor mobiele apparaten geen optie maar een verplichting.

Wanneer is een vulnerability scan zinvol voor mobiele omgevingen?

Een vulnerability scan is zinvol voor mobiele omgevingen zodra medewerkers smartphones of tablets gebruiken voor toegang tot bedrijfssystemen, en zeker wanneer er geen actueel inzicht is in de beveiligingsstatus van die apparaten. Scans helpen kwetsbaarheden te identificeren in apps, configuraties en netwerkkoppelingen voordat aanvallers ze kunnen misbruiken.

Specifieke momenten waarop een scan bijzonder waardevol is:

• Bij de introductie van een nieuw MDM-platform of een wijziging in het apparaatbeleid
• Na een beveiligingsincident waarbij een mobiel apparaat betrokken was
• Wanneer de organisatie overstapt van BYOD naar COPE of een ander model
• Als onderdeel van een bredere penetratietest of beveiligingsaudit
• Bij voorbereiding op NIS2-compliance of een externe audit

Een vulnerability scan voor mobiele omgevingen richt zich op aspecten als verouderde app-versies, onveilige netwerkconfiguraties, zwakke authenticatie-instellingen en mogelijke datalekken via app-permissies. Het resultaat is een concreet overzicht van risico’s met prioritering, zodat de IT-afdeling gericht actie kan ondernemen.

Reguliere scans, bij voorkeur meerdere keren per jaar, geven organisaties een actueel beeld van hun kwetsbaarhedenprofiel. In een omgeving waar apparaten en apps voortdurend veranderen, is een eenmalige scan onvoldoende. Structureel testen hoort bij een volwassen aanpak van mobiele beveiliging.

Hoe Q-Cyber helpt met de beveiliging van mobiele apparaten

Wij helpen organisaties om mobiele beveiliging structureel en pragmatisch aan te pakken, van beleid tot technische uitvoering. Of je nu worstelt met het opzetten van een BYOD-beleid, wil weten hoe kwetsbaar je mobiele omgeving is, of moet voldoen aan NIS2-verplichtingen: wij denken met je mee en leveren concrete resultaten.

Wat wij voor je kunnen doen:

• Opstellen van een mobiel beveiligingsbeleid dat aansluit op jouw organisatie en risicoprofiel
• Uitvoeren van vulnerability scans op mobiele omgevingen om kwetsbaarheden in kaart te brengen
• Advies over MDM-implementatie, onafhankelijk van softwarepartijen
• NIS2-begeleiding, inclusief gap-analyse, beleidsschrijving en trainingen voor bestuurders
• Bewustwordingstrainingen voor medewerkers over veilig gebruik van mobiele apparaten
• Virtuele CISO-diensten via Continuous-Q voor doorlopend advies en toezicht

Wij werken onafhankelijk, zonder binding aan softwareleveranciers, en leveren advies dat echt past bij jouw situatie. Wil je weten waar jouw organisatie nu staat? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer