VIOMS Blog

Categorie: Cybersecurity

  • TeamCity-lek CVE-2026-63077 wordt actief misbruikt: dit moet je nu doen

    TeamCity-lek CVE-2026-63077 wordt actief misbruikt: dit moet je nu doen

    Gebruik je TeamCity On-Premises als CI/CD-server? Dan is dit het moment om even alles anders te laten liggen. JetBrains liet op 7 augustus 2026 weten dat het kritieke lek CVE-2026-63077 inmiddels daadwerkelijk wordt misbruikt door aanvallers. Servers die nog niet zijn bijgewerkt, lopen op dit moment een reëel risico op volledige overname.

    In dit artikel leggen we uit wat het lek precies doet, waarom juist een build- en releaseserver zo’n aantrekkelijk doelwit is, welke versies veilig zijn, hoe je stap voor stap controleert of jouw omgeving is geraakt en welke maatregelen je structureel zou moeten nemen.

    Wat is er aan de hand?

    JetBrains publiceerde eind juli 2026 een beveiligingsmelding over een kritieke kwetsbaarheid in TeamCity On-Premises, met kenmerk CVE-2026-63077. Tegelijk met die melding waren er al gepatchte versies en een losse patch-plug-in beschikbaar. Ruim een week later volgde een aanvullende waarschuwing: er komen meldingen binnen van zowel geslaagde als mislukte aanvalspogingen op TeamCity-servers die nog niet zijn bijgewerkt.

    Daarmee verschuift de situatie van “belangrijk om snel op te pakken” naar “nu direct handelen”. Zodra een kwetsbaarheid in het wild wordt uitgebuit, worden kwetsbare systemen doorgaans binnen enkele dagen geautomatiseerd gescand en aangevallen. Het maakt daarbij niet uit hoe klein of onbekend je organisatie is: aanvallers zoeken op poort en protocol, niet op naam.

    Gebruik je TeamCity Cloud? Dan hoef je zelf niets te doen. JetBrains heeft de benodigde maatregelen daar al doorgevoerd. Deze blog gaat dus specifiek over zelf beheerde (on-premises of in eigen cloudomgeving gehoste) TeamCity-servers.

    Waarom dit lek zo gevaarlijk is

    Er is geen inlog nodig

    De kwetsbaarheid is uit te buiten zonder authenticatie. Iedereen die via HTTP of HTTPS bij je TeamCity-server kan komen, kan de aanval uitvoeren via het protocol waarmee build-agents de server bevragen. Er zijn dus geen gestolen wachtwoorden, tokens of interne toegang nodig. Bij succes voert de aanvaller commando’s uit op het besturingssysteem, met dezelfde rechten als het TeamCity-serverproces.

    Je secrets liggen op één plek

    Een CI/CD-server is per definitie een verzamelplaats van gevoelige gegevens: verbindingsgegevens naar repositories, deploytokens voor productieomgevingen, cloud-credentials, certificaten en API-keys. Wordt de server overgenomen, dan zijn niet alleen de projectconfiguraties en build-historie in gevaar, maar in potentie alle systemen waar die server naartoe mag deployen.

    Supply chain-risico voor je eigen software

    Het meest onderschatte gevolg is manipulatie van de build zelf. Een aanvaller die build-stappen of artifacts kan aanpassen, kan kwaadaardige code meesturen in software die jij vervolgens zelf naar productie of naar je klanten uitrolt. Zo’n aanpassing valt niet op in je broncode, omdat de wijziging pas ná de checkout gebeurt. Dat maakt een gecompromitteerde buildserver tot een probleem dat verder reikt dan één server.

    Welke versies zijn veilig?

    JetBrains heeft het probleem verholpen in TeamCity 2025.11.7 en 2026.1.3. Draai je een oudere release en kun je niet meteen upgraden, dan is er een security patch plug-in beschikbaar voor TeamCity 2017.1 en nieuwer. Let op: die plug-in dicht uitsluitend dit ene lek en is dus een tijdelijke noodmaatregel, geen alternatief voor bijwerken.

    SituatieActie nodig?Wat je moet doen
    TeamCity 2025.11.x vóór 2025.11.7Ja, directBijwerken naar 2025.11.7
    TeamCity 2026.1.x vóór 2026.1.3Ja, directBijwerken naar 2026.1.3
    Oudere versies (vanaf 2017.1)Ja, directUpgraden, of tijdelijk de security patch plug-in installeren
    TeamCity 2025.11.7 / 2026.1.3 of nieuwerNeeWel controleren op eerdere aanvalspogingen
    TeamCity CloudNeeJetBrains heeft dit al afgehandeld

    Wat je nu moet doen

    1. Breng in kaart welke servers je hebt

    Begin met de vraag die vaak wordt overgeslagen: waar draait TeamCity eigenlijk allemaal? Naast de productie-instantie zijn er in de praktijk vaak vergeten test- of legacy-servers, of een oude instantie die “voor de zekerheid” nog aan staat. Controleer per server het versienummer en of de server vanaf internet bereikbaar is.

    2. Werk bij naar een gepatchte versie

    Bijwerken naar 2025.11.7 of 2026.1.3 is de enige volledige oplossing. Maak vooraf een back-up van de datamap en de database, plan een kort onderhoudsvenster en controleer na de upgrade of agents weer verbinden en builds normaal draaien. Loopt de upgrade over meerdere stappen? Zorg dan dat de server tijdens dat traject niet vanaf internet bereikbaar is.

    3. Kun je niet direct bijwerken? Dicht de deur

    Lukt bijwerken niet op korte termijn, installeer dan de security patch plug-in én beperk tegelijk de netwerktoegang. Staat de server publiek open, haal hem dan tijdelijk achter een VPN of firewallregel tot je de fix hebt toegepast. Externe bereikbaarheid intrekken is bijna altijd sneller te regelen dan een volledige upgrade, en verkleint het risico onmiddellijk.

    Controleren op misbruik: waar let je op?

    Patchen is stap één, maar de vraag “is er al iets gebeurd?” is even belangrijk. JetBrains noemt drie concrete aanwijzingen die je zelf kunt nalopen in de serverlogs en de beheerinterface.

    Verdachte logmelding

    Zoek in de TeamCity-serverlogs op com.thoughtworks.xstream.converters.ConversionException. Deze melding alleen bewijst geen inbraak, maar kan wijzen op een poging of een geslaagde aanval en verdient nader onderzoek.

    Geblokkeerde poging

    Heb je al gepatcht? Zoek dan op com.thoughtworks.xstream.security.ForbiddenClassException. Die melding betekent dat iemand het heeft geprobeerd nádat de fix actief was en dat de poging is tegengehouden.

    Onbekende build-agents

    Bekijk de lijst met niet-geautoriseerde agents. Onverwachte namen die met scan beginnen, duiden op een aanvalspoging tegen een server die van buitenaf bereikbaar was. Zulke agents mag je verwijderen.

    Belangrijk detail bij die laatste controle: de datum die bij een niet-geautoriseerde agent staat, zegt niets over het moment van de aanvalspoging. Gebruik voor tijdlijnen altijd de timestamps uit de logbestanden. Twijfel je over de interpretatie van je logs, dan kun je een ticket openen bij de TeamCity-support van JetBrains.

    Wat te doen bij een vermoeden van misbruik

    Vind je aanwijzingen dat de aanval bij jou is geslaagd, ga dan uit van een volledig gecompromitteerde server. Patchen alleen verwijdert namelijk niet wat een aanvaller al heeft achtergelaten of meegenomen. Werk in dat geval de volgende punten af:

    1. Isoleer de server van internet en van omgevingen waar hij naartoe kan deployen, voordat je verder onderzoekt.
    2. Bewaar bewijs. Maak kopieën van logs en van de datamap voordat je gaat opschonen of herinstalleren.
    3. Roteer alle secrets die op de server stonden: deploytokens, SSH-keys, cloud-credentials, certificaten en API-keys. Ga ervan uit dat alles wat de server kon lezen, is gelezen.
    4. Controleer build-configuraties op onverwachte wijzigingen, extra build-stappen of gewijzigde scripts.
    5. Verifieer recente artifacts en releases die na de eerste verdachte logregel zijn gebouwd, en bouw ze bij twijfel opnieuw vanaf een schone omgeving.
    6. Controleer accounts en rechten in TeamCity zelf en op de onderliggende server, inclusief nieuwe gebruikers, tokens en geplande taken.
    7. Documenteer je bevindingen en beoordeel of er een meldplicht geldt, bijvoorbeeld richting de Autoriteit Persoonsgegevens of vanuit NIS2-verplichtingen.

    Structurele maatregelen voor je CI/CD-omgeving

    Dit lek is opgelost, maar het volgende komt er ooit. Een buildserver verdient daarom dezelfde bescherming als je andere kroonjuwelen. Deze drie pijlers beperken de schade van een toekomstige kwetsbaarheid aanzienlijk:

    Netwerktoegang beperken

    • Niet direct aan het internet hangen
    • Toegang via VPN of extra beveiligingslaag
    • Alleen vertrouwde netwerken toestaan
    • Agents in een apart netwerksegment

    Minimale rechten

    • Serverproces met zo weinig rechten als mogelijk
    • Server op een eigen host, los van build-agents
    • Deploytokens beperken tot wat echt nodig is
    • Secrets in een kluis, niet in build-configuraties

    Patchen en monitoren

    • Vaste updateronde voor CI/CD-tooling
    • Abonneren op security-advisories van je leveranciers
    • Logs centraal wegschrijven en bewaren
    • Alerteren op onbekende agents en afwijkende builds

    De compliance-kant: dit is geen vrijblijvend advies

    Val je onder NIS2, dan is het tijdig verwerken van bekende kwetsbaarheden geen kwestie van goede bedoelingen, maar onderdeel van je zorgplicht. Aantoonbaar patchmanagement, logging die je daadwerkelijk kunt terugzoeken en een incidentproces dat werkt, zijn precies de onderdelen waar bij een audit of incident naar wordt gekeken. Een misgelopen update op een buildserver is dan niet alleen een technisch risico, maar ook een aantoonbaar tekortkomen in je beheerproces.

    Verwerk deze casus daarom ook administratief: leg vast wanneer je hebt gepatcht, wat je in de logs hebt gecontroleerd en welke conclusie je daaraan verbond. Dat kost een kwartier en is later goud waard.

    Conclusie

    CVE-2026-63077 is het type kwetsbaarheid waar je niet mee wilt wachten: geen authenticatie nodig, uitvoering van commando’s op de server en een doelwit dat toegang heeft tot vrijwel al je omgevingen. Nu er actief misbruik is gemeld, is bijwerken naar 2025.11.7 of 2026.1.3 de belangrijkste taak van vandaag. Direct daarna volgt de controle of er in jouw logs al sporen te vinden zijn.

    De volledige technische melding en de instructies voor de patch-plug-in staan in de aanvullende blogpost van JetBrains. Wil je hulp bij het bijwerken, het nalopen van je logs of het structureel dichtzetten van je CI/CD-omgeving? Neem dan contact met ons op.

    1. Actief misbruik gemeld: onbijgewerkte TeamCity On-Premises-servers worden nu daadwerkelijk aangevallen.
    2. Fix beschikbaar: update naar TeamCity 2025.11.7 of 2026.1.3; de patch-plug-in is enkel een tijdelijke noodoplossing.
    3. Geen inlog nodig: een aanvaller met HTTP(S)-toegang kan commando’s uitvoeren met de rechten van het serverproces.
    4. Controleer je logs op de genoemde exception-meldingen en je agentlijst op onbekende namen die met scan beginnen.
    5. Bij vermoeden van inbraak: isoleer, bewaar bewijs, roteer alle secrets en verifieer je recente builds.
    6. TeamCity Cloud-klanten hoeven zelf niets te doen.
  • MFA en conditional access: verder dan een sms-code

    MFA en conditional access: verder dan een sms-code

    De meeste incidenten in MKB-omgevingen beginnen niet met een geavanceerde aanval op de firewall, maar met een geldig wachtwoord in verkeerde handen. Multifactorauthenticatie is daar het antwoord op, en veel organisaties hebben het inmiddels aan staan. Toch verschilt de bescherming die u eraan overhoudt sterk per implementatie: de ene vorm van MFA houdt een phishingaanval tegen, de andere niet.

    Wat MFA wel en niet oplost

    MFA zorgt ervoor dat een gestolen wachtwoord op zichzelf niet genoeg is om binnen te komen. Dat is een grote stap, want wachtwoorden lekken doorlopend via datasets van andere diensten en via nagemaakte inlogpagina’s. Wat MFA niet oplost: malware op een werkplek die een geldige sessie meeneemt, protocollen die de tweede factor helemaal niet ondersteunen, en uitzonderingen die iemand ooit “tijdelijk” heeft aangezet. Wie MFA inricht, richt dus vooral het geheel eromheen in. Dat valt onder identity en access management.

    Niet elke tweede factor is even sterk

    Er zijn grofweg drie niveaus in gebruik. Het verschil zit in de vraag of een aanvaller de tweede factor kan onderscheppen of aan de gebruiker kan ontfutselen.

    Code via sms of e-mail

    De zwakste variant. Een code is net zo goed door te geven aan een nagemaakte inlogpagina als een wachtwoord, en sms is gevoelig voor simkaartfraude.

    • Beter dan alleen een wachtwoord
    • Onderschepbaar en phishbaar
    • Alleen als tijdelijke tussenstap

    Authenticator met nummermatching

    De gebruiker neemt een nummer over van het inlogscherm naar de app. Blind op “goedkeuren” tikken kan niet meer, en dat blokkeert de meeste massale pogingen.

    • Geen blinde goedkeuring
    • Werkt ook zonder mobiel bereik
    • Inbegrepen in Microsoft 365

    Passkey of hardwaresleutel

    De sleutel is cryptografisch gebonden aan het echte inlogdomein. Een nagemaakte pagina krijgt niets bruikbaar, ook niet als de gebruiker meewerkt.

    • Phishing-resistent
    • Geen code om over te typen
    • Begin hiermee bij beheerders

    MFA-moeheid en pushmeldingen

    Zodra een aanvaller een wachtwoord heeft, is een veelgebruikte tactiek om eindeloos inlogpogingen te doen tot de gebruiker de melding uit ergernis goedkeurt, vaak midden in de nacht. Nummermatching haalt die tactiek onderuit, omdat er geen knop meer is om zomaar op te tikken. Vertel gebruikers daarbij expliciet wat ze doen bij een melding die ze niet zelf hebben veroorzaakt: niet negeren, maar melden bij de helpdesk, want het betekent dat hun wachtwoord bekend is.

    Conditional access: voorwaarden in plaats van alles of niets

    MFA bij elke aanmelding op elk apparaat levert weerstand op bij gebruikers en dus creatieve omwegen. Met conditional access maakt u de eis afhankelijk van de situatie: wie, waarvandaan, op welk apparaat en naar welke data. Onderstaande set regels werkt voor de meeste organisaties met tien tot tweehonderdvijftig werkplekken.

    SituatieRegelGevolg voor de gebruiker
    Beheerd apparaat, bekende locatieApparaat moet compliant zijnAanmelden zonder extra stappen
    Onbekend of prive-apparaatMFA verplicht, geen download van bestandenWebtoegang, lezen en bewerken in de browser
    Beheerdersrol gebruikenPhishing-resistente MFA verplichtPasskey of hardwaresleutel
    Aanmelding uit een land waar u niet werktBlokkerenMelding bij de beheerder

    Zet elke nieuwe regel eerst in rapportagemodus. U ziet dan een week mee wie erdoor geraakt zou worden, zonder dat iemand buitengesloten raakt. Voor de inrichting binnen Microsoft 365 gaat dit hand in hand met de beveiliging van uw Microsoft 365-omgeving.

    Wat u minimaal regelt

    1. MFA voor alle accounts, dus ook voor beheerders, directie en accounts die u zelden gebruikt.
    2. Verouderde aanmeldprotocollen blokkeren. Blijft POP, IMAP of SMTP met alleen een wachtwoord open, dan is uw MFA omzeilbaar. Dit hoort bij e-mailbeveiliging.
    3. Twee noodaccounts buiten de regels, met lange unieke wachtwoorden in een kluis en een alarm zodra ze gebruikt worden. Zonder die accounts sluit een foute regel u buiten uw eigen omgeving.
    4. Toegang tot bedrijfsdata koppelen aan de staat van het apparaat, wat vraagt om centraal endpoint management.
    5. Uitzonderingen alleen met einddatum en met een naam erbij, en elk kwartaal opnieuw langs.

    Licenties en randvoorwaarden

    Basis-MFA zit in elke Microsoft 365-omgeving. Voor conditional access heeft u Entra ID P1 nodig, dat onderdeel is van Microsoft 365 Business Premium. Voor de meeste MKB-organisaties is dat voldoende; u heeft geen enterprise-licentie nodig om bovenstaande regels in te voeren. Houd er rekening mee dat u de inrichting moet kunnen aantonen, bijvoorbeeld richting een verzekeraar of in het kader van de NIS2-richtlijn en uw AVG-verplichtingen.

    Invoeren zonder chaos op de helpdesk

    De praktische kant wordt vaak onderschat. Reken op een korte registratieperiode waarin gebruikers zelf hun app of sleutel koppelen, met een duidelijke einddatum en een instructie van een half A4. Begin met de IT-beheerders, dan een afdeling die meedenkt, daarna de rest. Plan de uitrol niet in een week met een deadline of een vakantiepiek, en zorg dat de helpdesk vooraf weet hoe een gebruiker weer toegang krijgt als de telefoon stuk of kwijt is. Die herstelprocedure is het onderdeel waar het in de praktijk op vastloopt, niet de techniek.

    Van invoering naar beheer

    Een eenmalige uitrol verliest binnen een jaar zijn waarde: er komen accounts bij, uitzonderingen blijven staan en apparaten vallen buiten beheer. Het onderhouden van deze regels hoort daarom bij proactief beheer, net als het opvolgen van meldingen. Gaat het ondanks alles mis, dan bepaalt uw voorbereiding hoe snel u weer werkt; dat leest u terug in ons artikel over herstel na een ransomware-aanval.

    Wilt u weten welke van deze regels in uw omgeving al actief zijn en welke uitzonderingen er nog open staan? Wij lopen uw aanmeldbeleid door en leveren een overzicht met concrete stappen, zonder dat uw mensen er iets van merken.

    Adviesgesprek aanvragen
  • BYOD beleid: risico’s en best practices

    BYOD beleid: risico’s en best practices

    Medewerkers die hun eigen smartphone, laptop of tablet gebruiken voor werkdoeleinden — het klinkt praktisch en kostenbesparend. Maar Bring Your Own Device (BYOD) brengt ook serieuze beveiligingsrisico’s met zich mee die je als organisatie niet kunt negeren. Zonder een duidelijk beleid loop je het risico op datalekken, infecties met malware en compliance-problemen.

    Toch hoeft BYOD geen probleem te zijn. Met de juiste aanpak combineer je de flexibiliteit die medewerkers willen met de beveiliging die jouw bedrijf nodig heeft. In dit artikel lees je wat BYOD precies inhoudt, welke risico’s er kleven aan een ongecontroleerde BYOD-omgeving en hoe je een effectief beleid opstelt.

    Wat is BYOD?

    BYOD staat voor Bring Your Own Device: medewerkers gebruiken hun persoonlijke apparaten — smartphones, laptops, tablets — voor werkgerelateerde taken. Ze lezen e-mail, werken in bedrijfssystemen of slaan documenten op via hun eigen hardware.

    BYOD is populair omdat het medewerkers flexibiliteit geeft en organisaties hardware-kosten bespaart. Maar het creëert ook een grijs gebied tussen privé en zakelijk gebruik, met alle beveiligingsuitdagingen van dien.

    Beveiligingsrisico’s

    Onbeheerde apparaten zijn een open deur voor malware, datalekken en ongeautoriseerde toegang tot bedrijfsdata.

    Compliance-uitdagingen

    AVG, NIS2 en sectorspecifieke regelgeving stellen eisen aan de beveiliging van data, ook op privéapparaten.

    Beheersbaarheid

    Zonder Mobile Device Management (MDM) heb je als IT-afdeling geen zicht op wat er op die apparaten gebeurt.

    De belangrijkste risico’s van BYOD

    1. Datalekken bij apparaatverlies of -diefstal

    Een gestolen smartphone zonder schermbeveiliging of encryptie geeft directe toegang tot zakelijke e-mail, bestanden en applicaties. Dit is niet alleen een beveiligingsprobleem — het kan ook een meldingsplichtig datalek zijn onder de AVG.

    2. Onbeveiligde netwerken

    Medewerkers verbinden hun apparaten vaak met openbare wifi-netwerken: in cafés, hotels of op luchthavens. Zonder VPN of Zero Trust-beveiliging kunnen aanvallers meelezen met het dataverkeer en inloggegevens onderscheppen.

    3. Verouderde software en ontbrekende updates

    Zakelijke apparaten worden centraal beheerd en voorzien van patches. Privéapparaten niet. Een medewerker die maanden achterloopt met updates draagt een apparaat met bekende kwetsbaarheden het bedrijfsnetwerk in.

    4. Schaduw-IT en ongeautoriseerde apps

    Op privéapparaten installeren medewerkers apps die niet door de IT-afdeling zijn goed- of afgekeurd. Zo belandt bedrijfsdata in consumentendiensten zonder zakelijke privacywaarborgen, of worden gevoelige bestanden gedeeld via niet-goedgekeurde kanalen.

    5. Problemen bij uitdiensttreding

    Wanneer een medewerker het bedrijf verlaat, moet je er zeker van zijn dat alle bedrijfsdata van zijn of haar persoonlijk apparaat is verwijderd. Zonder MDM is dat nauwelijks afdwingbaar — en kan data lang na vertrek nog toegankelijk zijn.

    Best practices voor een effectief BYOD-beleid

    Stel een duidelijk BYOD-beleid op

    De basis is een schriftelijk beleid dat medewerkers ondertekenen. Dit document beschrijft welke apparaten zijn toegestaan, welke apps verboden zijn, welke data beschikbaar is via privéapparaten en wat de consequenties zijn bij misbruik of verlies.

    Implementeer Mobile Device Management (MDM)

    MDM-oplossingen zoals Microsoft Intune stellen je in staat om zakelijke data op privéapparaten te beheren en te scheiden van persoonlijke inhoud. Via een MDM kun je op afstand de zakelijke container wissen, beleid afdwingen en apps centraal beheren — zonder toegang tot persoonlijke foto’s of berichten van de medewerker.

    Verplicht multi-factor authenticatie (MFA)

    Zelfs als een inlogcombinatie wordt gestolen via phishing of via een onbeveiligd netwerk, voorkomt MFA dat aanvallers daadwerkelijk toegang krijgen. MFA is een minimumvereiste voor elk apparaat dat toegang heeft tot bedrijfssystemen.

    Gebruik een Zero Trust-benadering

    Zero Trust gaat uit van het principe “vertrouw nooit, verifieer altijd”. Elk apparaat — ook een bekende laptop — moet zich bij iedere sessie opnieuw authenticeren en bewijzen dat het voldoet aan de beveiligingseisen. Dit beperkt de schade als een apparaat gecompromitteerd raakt.

    Vereis encryptie en schermbeveiliging

    Apparaten die toegang hebben tot bedrijfsdata moeten versleuteld zijn en beveiligd zijn met een pincode, wachtwoord of biometrie. Dit is de minimale drempel bij diefstal of verlies.

    Train medewerkers regelmatig

    Technische maatregelen helpen, maar medewerkers zijn de eerste verdedigingslinie. Zorg voor periodieke bewustwordingstraining over phishing, veilig wifi-gebruik, het herkennen van verdachte apps en de juiste omgang met zakelijke data op privéapparaten.

    BYOD vs. COPE vs. CYOD: wat past bij jouw organisatie?

    BYOD is niet de enige optie. Er zijn meerdere modellen voor apparaatbeheer, elk met een andere verhouding tussen vrijheid en controle:

    • BYOD (Bring Your Own Device): medewerker is eigenaar, organisatie stelt beveiligingseisen.
    • COPE (Corporate-Owned, Personally Enabled): bedrijf is eigenaar, medewerker mag het apparaat ook privé gebruiken.
    • CYOD (Choose Your Own Device): medewerker kiest uit een goedgekeurde lijst, bedrijf koopt en beheert het apparaat.
    • COBO (Corporate-Owned, Business Only): zakelijk apparaat, uitsluitend voor werkdoeleinden.

    Voor kleinere organisaties met beperkt IT-budget is BYOD met MDM vaak de meest pragmatische keuze. Grotere of meer risicovolle omgevingen kiezen vaker voor COPE of CYOD.

    Veelgemaakte fouten bij BYOD-beleid

    • Geen schriftelijk beleid: mondeling afspraken maken werkt niet als er iets misgaat.
    • MDM overgeslagen: zonder technisch beheer heb je geen grip op wat er op apparaten gebeurt.
    • MFA niet verplicht: één wachtwoord is onvoldoende bescherming voor zakelijke systemen.
    • Uitdiensttreding niet geregeld: zorg voor een vast offboarding-proces waarbij zakelijke data altijd wordt gewist.
    • Medewerkers niet getraind: beleid zonder bewustwording werkt niet.

    Hoe begin je met een BYOD-beleid?

    Stel jezelf eerst de volgende vragen:

    • Welke medewerkers gebruiken al privéapparaten voor werk — met of zonder officieel beleid?
    • Welke bedrijfsdata is bereikbaar via deze apparaten?
    • Hebben wij een MDM-oplossing of is dat nog niet geïmplementeerd?
    • Is er een offboarding-procedure die ook apparaatbeheer omvat?
    • Voldoen wij aan de AVG-vereisten voor de verwerking van data op privéapparaten?

    Op basis van de antwoorden kun je prioriteren: start met een beleidsdocument, implementeer MFA en MDM, en zorg daarna voor bewustwordingstraining.

    Conclusie

    BYOD is een realiteit in de moderne werkomgeving. Medewerkers gebruiken hun eigen apparaten — of je nu een beleid hebt of niet. De vraag is dus niet of je BYOD toestaat, maar hoe je het veilig inricht.

    1. Stel een schriftelijk BYOD-beleid op dat medewerkers ondertekenen.
    2. Implementeer MDM om zakelijke data te scheiden en te beheren.
    3. Verplicht MFA voor toegang tot alle bedrijfssystemen.
    4. Pas Zero Trust toe als beveiligingsfilosofie voor apparaat- en netwerktoegang.
    5. Vereis encryptie en schermbeveiliging op alle toegestane apparaten.
    6. Train medewerkers regelmatig over veilig gebruik van privéapparaten.
    7. Regel uitdiensttreding zodat zakelijke data altijd wordt gewist bij vertrek.
  • AVG en IT: wat moet je als MKB geregeld hebben?

    AVG en IT: wat moet je als MKB geregeld hebben?

    De Algemene Verordening Gegevensbescherming (AVG) is al jaren van kracht, maar nog steeds worstelen veel MKB-bedrijven met de vraag: wat moet ik nu precies geregeld hebben? De AVG is van toepassing op iedere organisatie die persoonsgegevens verwerkt van personen in de EU — en dat is vrijwel elk bedrijf, van ZZP’er tot multinational.

    In dit artikel richten we ons specifiek op de IT-kant van de AVG: welke technische en organisatorische maatregelen zijn vereist, wat zijn de meest voorkomende fouten en hoe begin je met een gestructureerde aanpak?

    Wat is de AVG en waarom is IT zo belangrijk?

    De AVG (in het Engels: GDPR) legt vast hoe organisaties persoonsgegevens mogen verzamelen, opslaan, gebruiken en beveiligen. IT speelt hierin een centrale rol: de meeste persoonsgegevens worden digitaal verwerkt, opgeslagen in databases, verstuurd via e-mail of bewaard in cloudomgevingen.

    Bij een datalek — zoals een hack, een verloren laptop of een verkeerd verstuurde e-mail — ben je als organisatie verplicht dit te melden bij de Autoriteit Persoonsgegevens (AP) en mogelijk ook aan de betrokkenen zelf. De gevolgen kunnen variëren van reputatieschade tot boetes van maximaal €20 miljoen of 4% van de wereldwijde jaaromzet.

    Verwerkingsregister

    Een overzicht van alle persoonsgegevens die je verwerkt, met welk doel, op welke basis en hoe lang je ze bewaart.

    Technische beveiliging

    Encryptie, toegangsbeheer, MFA en regelmatige back-ups zijn verplichte technische maatregelen onder de AVG.

    Verwerkersovereenkomst

    Met elke externe partij die persoonsgegevens voor jou verwerkt (zoals een cloudprovider of HR-systeem) moet je een verwerkersovereenkomst afsluiten.

    De 7 belangrijkste IT-verplichtingen onder de AVG

    1. Verwerkingsregister bijhouden

    Je moet documenteren welke persoonsgegevens je verwerkt, voor welk doel, op welke rechtmatige grondslag (toestemming, contract, wettelijke verplichting, etc.), hoe lang je ze bewaart en wie er toegang toe heeft. Dit is de basis van AVG-compliance en tegelijkertijd het vertrekpunt voor een goed IT-beleid.

    2. Passende technische beveiliging

    De AVG vereist “passende technische maatregelen” — wat dat precies betekent hangt af van de aard van de gegevens. Voor een gemiddeld MKB-bedrijf omvat dit minimaal:

    • Encryptie van gevoelige data, zowel in opslag als tijdens transport (HTTPS, versleutelde e-mail)
    • Toegangsbeheer op basis van het least privilege-principe: medewerkers krijgen alleen toegang tot de data die ze nodig hebben
    • Multi-factor authenticatie (MFA) voor alle systemen met persoonsgegevens
    • Regelmatige back-ups en een herstelstrategie bij dataverlies
    • Patchbeheer: systemen up-to-date houden om bekende kwetsbaarheden te dichten

    3. Verwerkersovereenkomsten afsluiten

    Elke externe partij die persoonsgegevens namens jou verwerkt — een cloudprovider, een HR-softwareleverancier, een IT-beheerder — is een “verwerker”. Met elke verwerker moet je een verwerkersovereenkomst (DPA) afsluiten. Deze overeenkomst legt vast hoe de verwerker met de gegevens omgaat en welke beveiligingsmaatregelen hij treft.

    4. Datalekken melden

    Bij een datalek — onbedoelde of onrechtmatige toegang tot, vernietiging, verlies of openbaarmaking van persoonsgegevens — moet je dit binnen 72 uur melden bij de Autoriteit Persoonsgegevens. Als het lek hoog risico oplevert voor de betrokkenen, moet je ook hen informeren. Een intern meldingsprotocol is essentieel om deze termijn te kunnen halen.

    5. Rechten van betrokkenen faciliteren

    Mensen hebben het recht om te weten welke gegevens je van hen hebt, om die te laten corrigeren of verwijderen (het “recht op vergetelheid”) en om bezwaar te maken tegen bepaalde verwerkingen. Je IT-systemen moeten zo zijn ingericht dat je aan deze verzoeken kunt voldoen — inclusief het daadwerkelijk verwijderen van data uit back-ups en archiven.

    6. Privacy by Design en Privacy by Default

    Bij de ontwikkeling of aanschaf van nieuwe systemen moet privacy standaard zijn ingebouwd. Dit betekent: verzamel niet meer gegevens dan noodzakelijk (dataminimalisatie), sla ze niet langer op dan nodig en maak de meest privacyvriendelijke instelling de standaard.

    7. Bewustwording en training

    De meeste datalekken ontstaan door menselijke fouten: een phishingmail, een verkeerd verstuurde e-mail of een verloren USB-stick. Periodieke training van medewerkers over gegevensbescherming is niet alleen verstandig — het is ook een AVG-vereiste.

    Veelgemaakte IT-fouten onder de AVG

    • Geen verwerkersovereenkomst met cloudproviders: veel organisaties gebruiken cloudtools zonder een DPA af te sluiten.
    • Data onbeperkt bewaren: gegevens worden standaard nooit verwijderd, terwijl de AVG verplicht tot een bewaartermijn.
    • Geen MFA op e-mail en bedrijfssystemen: e-mail is de grootste bron van datalekken bij MKB.
    • Geen back-up van persoonsgegevens: verlies van persoonsgegevens door systeemuitval is ook een datalek.
    • Geen meldingsprotocol: zonder vooraf nagedacht proces mis je de 72-uurstermijn bij een incident.

    Hoe begin je met AVG-compliance in IT?

    Een pragmatische aanpak voor het MKB:

    • Start met een verwerkingsregister: breng in kaart welke systemen persoonsgegevens verwerken.
    • Controleer je verwerkersovereenkomsten: heb je er een met elke externe dienst die data verwerkt?
    • Implementeer MFA en toegangsbeheer: dit is zowel een AVG-vereiste als goede beveiligingspraktijk.
    • Stel een intern meldingsprotocol op: wie beslist of iets een datalek is, en wie meldt het bij de AP?
    • Train je medewerkers: minimaal eenmaal per jaar over herkennen en melden van datalekken.

    Conclusie

    AVG-compliance in IT hoeft niet overweldigend te zijn. Door systematisch te werken — van verwerkingsregister tot technische beveiliging en bewustwording — bouw je een solide basis die zowel juridisch houdbaar is als jouw bedrijf en klanten beschermt.

    1. Verwerkingsregister — documenteer welke gegevens je verwerkt, waarom en hoe lang.
    2. Technische beveiliging — encryptie, MFA, toegangsbeheer en patchbeheer zijn verplicht.
    3. Verwerkersovereenkomsten — sluit DPA’s af met alle externe verwerkers.
    4. Datalekprotocol — zorg dat je de 72-uurstermijn kunt halen.
    5. Rechten van betrokkenen — systemen moeten verwijdering en export van data ondersteunen.
    6. Training — menselijke fouten zijn de voornaamste oorzaak van datalekken.
  • Wat betekent de NIS2-richtlijn voor jouw bedrijf?

    Wat betekent de NIS2-richtlijn voor jouw bedrijf?

    De NIS2-richtlijn is de meest ingrijpende Europese cybersecuritywetgeving van de afgelopen jaren. Waar de oorspronkelijke NIS-richtlijn uit 2016 nog beperkt was in reikwijdte, verplicht NIS2 een veel grotere groep organisaties tot concrete maatregelen op het gebied van cyberbeveiliging en incidentrapportage. Veel MKB-bedrijven weten nog niet of — en in hoeverre — zij onder de richtlijn vallen.

    In dit artikel leggen we uit wat NIS2 inhoudt, voor wie het geldt, wat de verplichtingen zijn en hoe je als organisatie aan de slag kunt.

    Wat is de NIS2-richtlijn?

    NIS2 staat voor Network and Information Security Directive 2. Het is een Europese richtlijn die lidstaten verplicht om wetgeving in te voeren die essentiële en belangrijke organisaties dwingt tot een minimumniveau van cyberbeveiliging. In Nederland wordt NIS2 omgezet via de Cyberbeveiligingswet (Cbw).

    Risicomaatregelen

    Organisaties moeten passende technische en organisatorische maatregelen treffen om cyberrisico’s te beheersen.

    Meldplicht

    Significante incidenten moeten binnen 24 uur gemeld worden, gevolgd door een volledig rapport binnen 72 uur.

    Bestuurlijke aansprakelijkheid

    Directie en bestuur zijn persoonlijk verantwoordelijk voor naleving. Bij ernstige overtredingen kunnen bestuurders tijdelijk worden geschorst.

    Voor wie geldt NIS2?

    NIS2 maakt onderscheid tussen twee categorieën organisaties:

    Essentiële entiteiten

    Grote organisaties in kritieke sectoren zoals energie, transport, gezondheidszorg, drinkwater, digitale infrastructuur en financiën. Deze organisaties vallen onder het strengste toezicht.

    Belangrijke entiteiten

    Middelgrote organisaties in een bredere groep sectoren, waaronder post en koeriersdiensten, afvalverwerking, voedselproductie, chemische industrie, onderzoek en digitale aanbieders.

    Geldt NIS2 ook voor het MKB?

    In principe richt NIS2 zich op middelgrote en grote organisaties (meer dan 50 medewerkers of meer dan €10 miljoen omzet). Kleine bedrijven vallen normaal gesproken buiten de directe scope. Maar als jij leverancier bent van een essentiële of belangrijke entiteit, kun je indirect verplicht worden om aan NIS2-eisen te voldoen via contractuele afspraken in de toeleveringsketen.

    Wat zijn de verplichtingen onder NIS2?

    1. Risicobeheer en beveiligingsmaatregelen

    Organisaties moeten een risicogebaseerde aanpak hanteren en passende maatregelen treffen, waaronder:

    • Beleid voor risicoanalyse en beveiliging van informatiesystemen
    • Incidentbeheer en -respons
    • Bedrijfscontinuïteit en crisismanagement
    • Beveiliging van de toeleveringsketen
    • Beheer van toegangsrechten en authenticatie (inclusief MFA)
    • Gebruik van encryptie en cryptografie
    • Personeelsbeveiliging en bewustwording

    2. Meldplicht bij incidenten

    • Binnen 24 uur: eerste melding (early warning) bij de toezichthouder.
    • Binnen 72 uur: een volledig incidentrapport met eerste analyse.
    • Binnen een maand: een eindrapport met oorzaak, impact en genomen maatregelen.

    3. Bestuurlijke verantwoordelijkheid

    Directie en bestuur zijn persoonlijk aansprakelijk voor het cybersecurity-beleid. Zij kunnen bij nalatigheid persoonlijk worden aangesproken en tijdelijk worden geschorst als de organisatie structureel in gebreke blijft.

    4. Toezicht en sancties

    Bij overtredingen kunnen boetes worden opgelegd van maximaal €10 miljoen of 2% van de wereldwijde jaaromzet (essentieel) of €7 miljoen of 1,4% omzet (belangrijk).

    Hoe bereid je jouw organisatie voor op NIS2?

    Stap 1: Bepaal of je onder NIS2 valt

    Controleer of jouw organisatie in een van de aangewezen sectoren actief is en voldoet aan de drempelwaarden. Kijk ook of jij leverancier bent van organisaties die onder NIS2 vallen.

    Stap 2: Voer een nulmeting uit

    Breng in kaart wat je huidige beveiligingsniveau is ten opzichte van de NIS2-vereisten. Welke maatregelen zijn al getroffen? Waar zitten de grootste lacunes?

    Stap 3: Stel een verbeterplan op

    Prioriteer de maatregelen op basis van risico en implementeerbaarheid. Denk aan: MFA invoeren, back-upbeleid aanscherpen, een incidentresponsplan opstellen en medewerkers trainen.

    Stap 4: Betrek het bestuur

    NIS2 vereist dat het bestuur actief betrokken is bij cybersecurity. Zorg dat directie de risico’s begrijpt, het beleid goedkeurt en periodiek wordt geïnformeerd over de status.

    Stap 5: Documenteer alles

    Toezichthouders verwachten aantoonbare naleving. Leg beleid, risicoanalyses, maatregelen en trainingen schriftelijk vast zodat je bij controle kunt aantonen wat je gedaan hebt.

    Veelgemaakte fouten bij NIS2-voorbereiding

    • Wachten tot de wet van kracht is: de vereiste maatregelen kosten tijd — begin nu.
    • Alleen technische maatregelen nemen: NIS2 vraagt ook om processen, beleid en bewustwording.
    • Bestuur niet betrekken: cybersecurity is een bestuursvraagstuk geworden.
    • Toeleveranciers vergeten: beveiliging van de supply chain is een expliciete vereiste.
    • Geen incidentresponsplan: zonder plan verlies je kostbare uren bij een incident.

    Conclusie

    NIS2 is geen administratieve formaliteit. Het is een fundamentele verschuiving in hoe Europa cybersecurity reguleert, met directe gevolgen voor bestuurders die de verantwoordelijkheid niet langer kunnen delegeren.

    1. Bepaal je scope — val je onder NIS2 als essentiële of belangrijke entiteit?
    2. Voer een nulmeting uit — waar sta je nu ten opzichte van de vereisten?
    3. Stel een verbeterplan op met prioriteit voor de grootste risico’s.
    4. Betrek het bestuur — zij zijn persoonlijk aansprakelijk.
    5. Documenteer alles om bij toezicht aantoonbaar compliant te zijn.
    6. Oefen je incidentrespons zodat je de meldtermijnen kunt halen.
  • Microsoft 365 Ransomware Recovery: wat te doen na een aanval

    Microsoft 365 Ransomware Recovery: wat te doen na een aanval

    Een ransomware-aanval op je Microsoft 365-omgeving is geen IT-incident dat je “even oplost”. Het raakt e-mail, bestanden, Teams, identiteiten, endpoints, compliance en vaak ook het vertrouwen van klanten en medewerkers. De belangrijkste vraag is niet alleen: hoe krijgen we onze data terug? Maar vooral: hoe herstellen we veilig zonder de aanvaller opnieuw binnen te laten?

    In deze blog lees je welke stappen je moet nemen na een ransomware-aanval op Microsoft 365, van eerste containment tot herstel, validatie en structurele verbetering.

    1. Begin niet met herstellen, maar met isoleren

    De grootste fout na een ransomware-aanval is te snel terugzetten. Als de aanvaller nog toegang heeft tot accounts, apparaten of applicaties, herstel je mogelijk naar een omgeving die direct opnieuw wordt versleuteld.

    Start daarom met containment:

    • Stop OneDrive-synchronisatie op getroffen apparaten.
    • Koppel gemapte SharePoint-drives los.
    • Blokkeer of reset verdachte gebruikersaccounts.
    • Trek actieve sessies en refresh tokens in.
    • Isoleer geïnfecteerde endpoints.
    • Beperk tijdelijk toegang tot kritieke SharePoint-sites, Teams en mailboxen.

    Microsoft adviseert bij ransomware in SharePoint Online onder meer om direct OneDrive sync te stoppen of de gemapte drive naar een SharePoint-bibliotheek los te koppelen. Daarna kan een beheerder of gebruiker proberen bestanden te herstellen via SharePoint, OneDrive of Microsoft 365 Backup.

    2. Bepaal de omvang van de aanval

    Een goed herstel begint met scope. Je moet weten wat is geraakt, wanneer het is begonnen en hoe de aanval binnenkwam.

    Breng minimaal in kaart:

    • Welke gebruikersaccounts zijn gecompromitteerd?
    • Welke apparaten zijn geraakt?
    • Welke SharePoint-sites, OneDrive-accounts, Teams-kanalen en mailboxen zijn beïnvloed?
    • Zijn bestanden versleuteld, verwijderd of overschreven?
    • Is er sprake van datadiefstal naast versleuteling?
    • Welke beheerdersrechten of app-consents zijn mogelijk misbruikt?

    Microsoft Incident Response benadrukt dat containment pas effectief kan plaatsvinden wanneer duidelijk is wat er precies moet worden ingesloten. Daarbij horen onder andere vragen over gecompromitteerde gebruikersaccounts, getroffen apparaten en getroffen applicaties.

    3. Vind het laatste schone herstelpunt

    Bij ransomware draait herstel om timing. Je zoekt het laatste moment waarop bestanden, mailboxen en sites nog schoon waren. Dat punt ligt vaak vóór de zichtbare versleuteling, omdat aanvallers al eerder toegang hadden.

    Gebruik signalen zoals:

    • Ongebruikelijke massale bestandswijzigingen.
    • Grote aantallen hernoemde bestanden.
    • Nieuwe extensies achter bestandsnamen.
    • Ransom notes zoals “HELP_DECRYPT” of “RECOVER”.
    • Veel bestanden met dezelfde “Modified By”-tijdstempel.
    • Alerts uit Microsoft Defender, Entra ID en audit logs.

    Microsoft noemt dit soort kenmerken expliciet als indicatoren van ransomware in SharePoint Online, waaronder corrupte bestanden, ransom notes, gewijzigde extensies en grote aantallen bestanden met dezelfde wijzigingstijd.

    4. Herstel Microsoft 365-data gecontroleerd

    Microsoft 365 biedt meerdere herstelmogelijkheden, afhankelijk van wat er is geraakt.

    SharePoint en OneDrive

    SharePoint en OneDrive beschikken over ingebouwde herstelmechanismen zoals versiegeschiedenis, prullenbak en file restore. Versioning bewaart standaard minimaal 500 versies van een bestand, waardoor een eerdere versie kan worden teruggezet als ransomware een bestand heeft aangepast of versleuteld. Verwijderde bestanden kunnen in veel gevallen tot 93 dagen uit de prullenbak worden hersteld.

    Belangrijk: herstel niet blind alles. Test eerst een beperkte set bestanden of sites, controleer of het herstelpunt schoon is en schaal daarna pas op.

    Exchange Online

    Voor mailboxen moet je bepalen of e-mails, agenda-items, contacten of taken zijn verwijderd, gewijzigd of misbruikt voor verdere aanvalspogingen. Microsoft 365 Backup ondersteunt herstel van Exchange mailbox-content vanaf specifieke eerdere punten in de tijd.

    Teams

    Teams-data is verspreid over Microsoft 365-services. Teams-bestanden staan in SharePoint of OneDrive, terwijl Teams-chats worden opgeslagen in Exchange Online-mailboxen. Dat betekent dat herstel van Teams meestal via SharePoint, OneDrive en Exchange Online loopt.

    5. Gebruik Microsoft 365 Backup of een passende backup-oplossing

    Ingebouwde Microsoft 365-herstelmogelijkheden zijn waardevol, maar bij grootschalige ransomware wil je vooral snel, consistent en op tenant-niveau kunnen herstellen.

    Microsoft 365 Backup is ontworpen voor herstel van SharePoint-sites, OneDrive-accounts en Exchange-mailboxen. Het ondersteunt herstel naar de oorspronkelijke locatie of naar een nieuwe locatie, en beheerders kunnen herstellen vanaf specifieke herstelpunten.

    Microsoft beschrijft Microsoft 365 Backup bovendien als een oplossing die organisaties sneller terug kan brengen naar een gezonde staat na ransomware of kwaadwillige verwijdering. De dienst werkt binnen de Microsoft 365 data trust boundary en gebruikt append-only backup storage om bestaande herstelpuntdata te beschermen tegen overschrijven.

    Heb je nog geen Microsoft 365 Backup of externe backup-oplossing? Dan is dit hét moment om je backupstrategie opnieuw te beoordelen.

    6. Valideer voordat je de organisatie weer openzet

    Herstel is pas klaar wanneer je zeker weet dat:

    • De aanvaller geen actieve toegang meer heeft.
    • Alle verdachte accounts zijn gereset of geblokkeerd.
    • Beheerdersrollen zijn gecontroleerd.
    • Kwaadaardige inboxregels, OAuth-apps en forwardingregels zijn verwijderd.
    • Endpoints schoon zijn verklaard.
    • Herstelde bestanden veilig en bruikbaar zijn.
    • Business owners akkoord geven op kritieke data.

    Een veilige recovery is dus geen puur technische restore. Het is een gecontroleerd besluit waarbij IT, security, management, legal en communicatie samenwerken.

    7. Communiceer helder met medewerkers

    Tijdens ransomware ontstaat snel verwarring. Medewerkers moeten weten wat ze wel en niet mogen doen.

    Communiceer bijvoorbeeld:

    • Open geen verdachte bestanden of ransom notes.
    • Sluit apparaten niet zomaar opnieuw aan op het netwerk.
    • Meld versleutelde of ontbrekende bestanden direct.
    • Gebruik tijdelijk alleen goedgekeurde communicatiekanalen.
    • Wacht met synchroniseren totdat IT bevestigt dat dit veilig is.

    Goede communicatie voorkomt dat de aanval zich verder verspreidt en helpt IT om sneller de volledige impact te bepalen.

    8. Leg alles vast voor onderzoek, verzekering en compliance

    Documenteer vanaf het eerste moment:

    • Tijdlijn van detectie, containment en herstel.
    • Betrokken accounts, apparaten en workloads.
    • Genomen maatregelen.
    • Herstelpunten en restore-acties.
    • Beslissingen van management.
    • Bewijs van mogelijke datadiefstal.
    • Communicatie met leveranciers, verzekeraar of toezichthouders.

    Microsoft Incident Response adviseert om tijdens incidentrespons werkitems, eigenaren, status, bevindingen, datum en tijd zorgvuldig vast te leggen.

    9. Voorkom herhaling: bouw ransomware-resilience in

    Na herstel begint het belangrijkste werk: zorgen dat dit niet opnieuw gebeurt. Versterk minimaal deze onderdelen:

    Identity Security

    • MFA voor alle gebruikers
    • Conditional Access policies
    • Privileged Identity Management
    • Sterke admin-segregatie

    Endpoint & E-mailbeveiliging

    • Microsoft Defender for Endpoint
    • Attack surface reduction rules
    • Patchmanagement
    • Defender for Office 365 / Safe Links

    Backup, Monitoring & Awareness

    • Retentiebeleid en versiebeheer
    • Backup en kwartaallijkse restore-tests
    • Audit logging en Defender XDR alerts
    • User awareness training op phishing

    Microsoft 365 bevat al meerdere verdedigingslagen tegen ransomware, waaronder Exchange Online Protection voor e-mail en bijlagen, en herstelmechanismen in SharePoint en OneDrive zoals versioning, prullenbak en retentiefunctionaliteit. Maar technologie werkt alleen goed als processen, verantwoordelijkheden en tests op orde zijn.

    Conclusie

    Microsoft 365 ransomware recovery draait niet alleen om bestanden terugzetten. Het gaat om gecontroleerd herstellen naar een betrouwbare staat. De juiste volgorde is cruciaal:

    1. Isoleer de aanval.
    2. Bepaal de scope.
    3. Vind het laatste schone herstelpunt.
    4. Herstel gecontroleerd.
    5. Valideer de omgeving.
    6. Documenteer alles.
    7. Versterk je beveiliging en backupstrategie.

    Ransomware is geen eenmalig IT-probleem, maar een test van je digitale weerbaarheid. Organisaties die vooraf nadenken over herstel, backup, identiteiten en incidentrespons staan na een aanval niet stil, maar kunnen sneller, veiliger en met meer vertrouwen terug naar normaal.