{"id":34306,"date":"2026-05-30T17:54:55","date_gmt":"2026-05-30T17:54:55","guid":{"rendered":"https:\/\/sunbytes.io\/wp\/blog\/uncategorized\/nis2-penetration-testing\/"},"modified":"2026-09-15T09:07:32","modified_gmt":"2026-09-15T09:07:32","slug":"nis2-penetration-testing","status":"publish","type":"post","link":"https:\/\/sunbytes.io\/nl\/blog\/cyberbeveiliging\/nis2-penetration-testing\/","title":{"rendered":"NIS2 penetration testing requirements: hoe compliance met Artikel 21(2) eruitziet"},"content":{"rendered":"\n

NIS2 penetration testing is geen checkbox-oefening. Artikel 21 noemt niet \u00e9\u00e9n specifieke testing tool die elke entiteit moet gebruiken. Het artikel verplicht organisaties om kwetsbaarheden te behandelen en te beoordelen of hun cybersecurity\u00adrisicobeheersmaatregelen in de praktijk werken.<\/p>\n\n\n\n

Dat onderscheid telt. Een vulnerability scan kan laten zien dat er een bekende zwakte bestaat. Een DAST scan kan een draaiende webapplicatie testen op veelvoorkomende issues. Een penetration test gaat verder: die controleert of zwaktes kunnen worden misbruikt, hoe ver een aanvaller kan komen en of bestaande controles de aanvalslijn stoppen.<\/p>\n\n\n\n

Voor EU-bedrijven die zich voorbereiden op NIS2 is de praktische vraag: \u201cKunnen wij bewijzen wat is getest, wat faalde, wat is hersteld en welk bewijs de finding afsluit?\u201d<\/p>\n\n\n\n

Dit artikel legt uit wat NIS2 Artikel 21<\/a><\/strong> betekent voor vulnerability testing<\/a><\/strong>, wanneer penetration testing<\/a><\/strong> het juiste bewijsmechanisme is, wat een NIS2-ready rapport moet bevatten en hoe Nederlandse organisaties MIAUW kunnen gebruiken als nuttige referentie voor testing met auditwaarde.<\/p>\n\n\n\n

TL;DR<\/h2>\n\n\n\n

NIS2 Artikel 21 vereist vulnerability handling onder Artikel 21(2)(e) en beoordeling van controle-effectiviteit onder Artikel 21(2)(f). Geautomatiseerde scans helpen bekende kwetsbaarheden te vinden, maar bewijzen niet of controles exploitatie voorkomen. Voor systemen met hoog risico kan een scoped penetration test<\/a><\/strong> sterker Artikel 21-bewijs opleveren: scope, methodologie, gevalideerde findings, remediation actions en retest results. Nederlandse organisaties kunnen MIAUW<\/a><\/strong> gebruiken als praktische referentie voor penetration testing met auditwaarde.<\/p>\n\n\n\n

\"NIS2<\/figure>\n\n\n\n

Vereist NIS2 penetration testing?<\/h2>\n\n\n\n

NIS2 verplicht organisaties om cybersecurityrisico\u2019s te beheersen met maatregelen die passend en proportioneel zijn ten opzichte van hun blootstelling. Artikel 21(2)(e) behandelt security bij aanschaf, ontwikkeling en onderhoud, inclusief vulnerability handling en disclosure. Artikel 21(2)(f) behandelt beleid en procedures om te beoordelen of cybersecurity\u00adrisicobeheersmaatregelen effectief zijn.<\/p>\n\n\n\n

Dat betekent niet dat elk systeem in elke organisatie elk jaar dezelfde penetration test nodig heeft. Het betekent dat de organisatie moet kunnen aantonen dat kwetsbaarheden worden gevonden, beoordeeld en hersteld, en dat security controls werken.<\/p>\n\n\n\n

Voor een intern low-risk tool kunnen vulnerability scanning en secure configuration review genoeg zijn. Voor een internet-facing application, betaalplatform, klantportal, operational technology gateway of API die gevoelige data verwerkt, is een handmatige penetration test vaak de sterkere bewijsroute.<\/p>\n\n\n\n

Een goed NIS2 testing plan moet drie vragen beantwoorden:<\/p>\n\n\n\n

    \n
  1. Welke systemen vallen binnen scope voor Artikel 21-risico?<\/li>\n\n\n\n
  2. Welke testing method bewijst dat het risico wordt beheerst?<\/li>\n\n\n\n
  3. Welk bewijs is voldoende voor management, auditors, klanten of toezichthouders?<\/li>\n<\/ol>\n\n\n\n

    Het antwoord kan vulnerability scanning, DAST, penetration testing, code review, configuration review of supplier testing evidence omvatten. Penetration testing wordt nodig wanneer de organisatie bewijs nodig heeft van exploitability en control effectiveness, niet alleen een lijst met bekende CVEs.<\/p>\n\n\n\n

    Welke NIS2 Artikel 21-verplichtingen vulnerability testing vereisen<\/h2>\n\n\n\n

    Artikel 21(2)(e) en Artikel 21(2)(f) zijn de twee relevante verplichtingen voor vulnerability testing.<\/p>\n\n\n\n

    Artikel 21(2)(e): vulnerability handling and disclosure<\/h3>\n\n\n\n

    Artikel 21(2)(e)<\/a><\/strong> vereist security bij de aanschaf, ontwikkeling en het onderhoud van netwerk- en informatiesystemen, inclusief vulnerability handling en disclosure.<\/p>\n\n\n\n

    In de praktijk betekent dit dat de organisatie een herhaalbaar proces nodig heeft om kwetsbaarheden te vinden, beoordelen, prioriteren, herstellen en documenteren. Vulnerability scans ondersteunen deze vereiste omdat ze bekende zwaktes identificeren in systemen, poorten, softwareversies, packages en configuraties.<\/p>\n\n\n\n

    Maar scanning alleen is niet het volledige proces. De organisatie heeft ook ownership, remediation tracking, exception handling, supplier coordination en bewijs nodig dat de finding is gesloten.<\/p>\n\n\n\n

    Artikel 21(2)(e) beantwoordt: \u201cHebben wij een proces om kwetsbaarheden te vinden en af te handelen?\u201d<\/p>\n\n\n\n

    Artikel 21(2)(f): control effectiveness assessment<\/h3>\n\n\n\n

    Artikel 21(2)(f) <\/a>vereist beleid en procedures om de effectiviteit van cybersecurity\u00adrisicobeheersmaatregelen te beoordelen.<\/p>\n\n\n\n

    Hier wordt penetration testing relevanter. Een scan kan detecteren dat een zwakte bestaat. Een penetration test controleert of die zwakte kan worden misbruikt ondanks de controles die de aanval zouden moeten voorkomen of beperken.<\/p>\n\n\n\n

    Een access control-regel kan bijvoorbeeld in beleid bestaan. Een penetration test kan laten zien of privilege escalation nog steeds mogelijk is. Een web application firewall kan geconfigureerd zijn. Een penetration test kan laten zien of deze de relevante aanvalslijn blokkeert. Logging kan zijn ingeschakeld. Een penetration test kan laten zien of de incident trail de juiste events vastlegt.<\/p>\n\n\n\n

    Artikel 21(2)(f) beantwoordt: \u201cKunnen wij bewijzen dat onze controles werken onder realistische aanvalsomstandigheden?\u201d<\/p>\n\n\n\n

    Als uw team nog alle 10 Artikel 21-maatregelen in kaart brengt, start dan met de bredere NIS2 Article 21 security requirements guide <\/a><\/strong>voordat u de testing scope vernauwt.<\/p>\n\n\n\n

    De drie NIS2 testing methods: wat elke methode dekt en wat niet<\/h2>\n\n\n\n

    NIS2 specificeert de uitkomst: vulnerability handling en control effectiveness. Het schrijft niet \u00e9\u00e9n tool voor.<\/p>\n\n\n\n

    Daarom telt de testing method. Een vulnerability scan, DAST scan en penetration test hebben allemaal een rol, maar zijn niet onderling uitwisselbaar.<\/p>\n\n\n\n

    Een bruikbaar testing plan begint met het scheiden van drie taken:<\/p>\n\n\n\n

    \u25cf Bekende kwetsbaarheden vinden.
    \u25cf Applicatiegedrag testen terwijl het systeem draait.
    \u25cf Bewijzen of een aanvaller zwaktes kan misbruiken en controles kan omzeilen.<\/p>\n\n\n\n

    Wanneer die taken door elkaar lopen, overschatten bedrijven vaak wat hun scanrapport bewijst. Het rapport kan bruikbaar zijn voor Artikel 21(2)(e), maar zwak voor Artikel 21(2)(f).<\/p>\n\n\n\n

    Vulnerability scan vs DAST vs penetration test: NIS2 compliance comparison<\/h2>\n\n\n\n
    Testing type<\/th>Wat het is<\/th>Welke NIS2 Artikel 21-maatregel het ondersteunt<\/th>Beperking \u2014 wat het niet dekt<\/th><\/tr><\/thead>
    Vulnerability scan<\/td>Geautomatiseerde scan van bekende CVEs, exposed services, poorten, softwareversies en misconfiguraties. Veelgebruikte tools zijn Nessus, Qualys en OpenVAS.<\/td>Ondersteunt Artikel 21(2)(e) door bekende kwetsbaarheden te helpen identificeren. Ondersteunt ook risicoanalyse wanneer findings worden geprioriteerd.<\/td>Kan kwetsbaarheden niet combineren, business logic niet testen, attack paths niet valideren of bewijzen of controles exploitatie stoppen.<\/td><\/tr>
    DAST<\/td>Dynamic Application Security Testing op een draaiende webapplicatie of API. Kan issues detecteren zoals XSS, SQL injection, weak authentication flows en API exposure.<\/td>Ondersteunt Artikel 21(2)(e) voor application vulnerability handling. Kan Artikel 21(2)(f) deels ondersteunen voor application control checks.<\/td>Dekt geen volledig infrastructuurrisico, supplier exposure, handmatige attack chains of complexe authorization flaws zonder menselijke validatie.<\/td><\/tr>
    Penetration test<\/td>Human-led gesimuleerde aanval binnen een gedefinieerde scope. Test exploitability, attack paths en of controles werken onder realistische omstandigheden.<\/td>Sterke ondersteuning voor Artikel 21(2)(e) en Artikel 21(2)(f), vooral voor high-risk systems.<\/td>Is point-in-time, afhankelijk van scope en geen vervanging voor doorlopend vulnerability management. Een smalle scope laat out-of-scope systems ongetest.<\/td><\/tr><\/tbody><\/table>
    Vulnerability scan vs DAST vs penetration test<\/figcaption><\/figure>\n\n\n\n

    NIS2 testing methods vullen elkaar aan. Een vulnerability scan helpt bekende issues te vinden; een penetration test is sterker bewijs wanneer de organisatie control effectiveness moet aantonen.<\/p>\n\n\n\n

    Een veelgemaakte compliancefout is een scanresultaat behandelen als bewijs dat controles werken. Dat is het niet. Een scan kan laten zien dat een server een patch mist. De scan kan niet laten zien of een aanvaller dat issue kan combineren met zwak toegangsbeheer, slechte segmentatie en exposed credentials om gevoelige data te bereiken. Gebruik voor de technische fases van scoping, exploitation, reporting en retesting de volledige penetration testing methodology guide<\/a><\/strong> als verdiepende referentie.<\/p>\n\n\n\n

    Voor NIS2-bewijs moet de testmethode passen bij het risico van het systeem. Hoe meer blootgesteld of bedrijfskritisch het systeem is, hoe meer de organisatie moet verschuiven van geautomatiseerde detectie naar gevalideerd bewijs van exploitability.<\/p>\n\n\n\n

    \"Vulnerability<\/figure>\n\n\n\n

    Hoe vaak moeten NIS2-entiteiten penetration testing uitvoeren?<\/h2>\n\n\n\n

    NIS2 legt geen vaste penetration testing cadence op voor elke entiteit. De veiligere formulering van de vereiste is: testing frequency moet risicogebaseerd, gedocumenteerd en bijgewerkt zijn wanneer de omgeving verandert.<\/p>\n\n\n\n

    Voor veel essential en important entities is een jaarlijkse penetration test voor high-risk systems een praktische bewijsbasislijn. Daarmee laat de organisatie zien dat zij niet alleen vertrouwt op historische scanresultaten. Het geeft management ook jaarlijks zicht op exploitability, remediation status en residual risk.<\/p>\n\n\n\n

    Jaarlijkse testing is niet genoeg wanneer er een grote wijziging plaatsvindt. Een gerichte test moet worden overwogen na wijzigingen zoals:<\/p>\n\n\n\n

    \u25cf een nieuwe internet-facing application,
    \u25cf een grote cloud migration,
    \u25cf een nieuw customer portal of API,
    \u25cf een significante identity and access management-wijziging,
    \u25cf onboarding van een critical supplier platform,
    \u25cf grote architecture changes die segmentatie of data flow be\u00efnvloeden.<\/p>\n\n\n\n

    Een praktische cadence kan er zo uitzien:<\/p>\n\n\n\n

    Trigger of entity context<\/th>Praktische penetration testing cadence<\/th>Vulnerability scan cadence<\/th>Bewijs om te bewaren<\/th><\/tr><\/thead>
    High-risk internet-facing systems<\/td>Minimaal jaarlijks, op basis van risico en scope<\/td>Maandelijks of per kwartaal, afhankelijk van blootstelling<\/td>Scope, findings, remediation plan, retest evidence<\/td><\/tr>
    Important business systems met gevoelige data<\/td>Jaarlijks of na grote wijziging<\/td>Per kwartaal of halfjaarlijks<\/td>Risk acceptance, scan results, remediation tracking<\/td><\/tr>
    Nieuwe applicatie of major release<\/td>Gerichte test v\u00f3\u00f3r of kort na release<\/td>Scan v\u00f3\u00f3r release en na remediation<\/td>Test report, release decision, unresolved risk sign-off<\/td><\/tr>
    Supplier-operated system binnen scope<\/td>Review supplier test evidence jaarlijks of bij verlenging<\/td>Vraag supplier scan of assurance evidence op waar relevant<\/td>Supplier report summary, exceptions, follow-up actions<\/td><\/tr><\/tbody><\/table>
    Een praktische cadence<\/figcaption><\/figure>\n\n\n\n

    NIS2 testing cadence moet risicogebaseerd zijn. Jaarlijkse testing is een praktische basislijn voor high-risk systems, geen universeel juridisch minimum.<\/p>\n\n\n\n

    De cadence moet worden gedocumenteerd in een beleid of security testing plan. Het plan moet aangeven welke systemen worden getest, welke methode wordt gebruikt, wie eigenaar is van remediation en wanneer retesting plaatsvindt.<\/p>\n\n\n\n

    Als een toezichthouder, sectorauthoriteit, klantcontract of cyber insurance requirement een strengere cadence stelt, moet die vereiste de algemene basislijn overrulen.<\/p>\n\n\n\n

    MIAUW: de Nederlandse standaard voor NIS2-compliant pentests<\/h2>\n\n\n\n

    Voor Nederlandse organisaties is MIAUW<\/a><\/strong> een nuttige methodologiereferentie wanneer penetration testing auditwaarde moet hebben. MIAUW staat voor Methodiek voor Informatiebeveiligingsonderzoek met Audit Waarde, of Methodology for Information Security Research with Audit Value.<\/p>\n\n\n\n

    De formulering telt. MIAUW moet niet worden gepresenteerd als NIS2-certificering. Het maakt een bedrijf niet vanzelf compliant. De waarde is dat het helpt om de test zo te structureren dat de uitkomst makkelijker te valideren, herhalen en presenteren is als bewijs.<\/p>\n\n\n\n

    Een MIAUW-style aanpak is nuttig voor NIS2 omdat Artikel 21(2)(f) niet alleen gaat over securitywerk uitvoeren. Het gaat om beoordelen of risicobeheersmaatregelen effectief zijn. Dat vereist traceability.<\/p>\n\n\n\n

    Een pentest met auditwaarde moet laten zien:<\/p>\n\n\n\n

    \u25cf wat is getest,
    \u25cf wat is uitgesloten,
    \u25cf welke methodologie is gebruikt,
    \u25cf welke findings zijn gevalideerd,
    \u25cf welk bewijs de finding ondersteunt,
    \u25cf welke remediation vereist is,
    \u25cf of de remediation opnieuw is getest.<\/p>\n\n\n\n

    Dat verschilt van een los \u201cethical hacker report\u201d waarin de scope onduidelijk is, severity scoring subjectief is en de klant het bewijs\u00adpad later niet kan reconstrueren.<\/p>\n\n\n\n

    Voor Nederlandse entiteiten die zich voorbereiden op de Cyberbeveiligingswet kan MIAUW procurement- en securityteams helpen om betere vragen te stellen voordat zij een test laten uitvoeren:<\/p>\n\n\n\n

    \u25cf Maakt het rapport scope en exclusions expliciet?
    \u25cf Gebruiken findings een consistente scoringmethode zoals CVSS?
    \u25cf Bevat het rapport exploit evidence waar exploitatie mogelijk was?
    \u25cf Worden retest results gedocumenteerd?
    \u25cf Is het rapport bruikbaar voor management en auditors, niet alleen voor engineers?<\/p>\n\n\n\n

    Download voor de volledige MIAUW-methodologiedetails<\/a><\/strong> onze checklist om te zorgen dat uw penetration tests voldoen aan het MIAUW framework, inconsistenties aanpakken en cybersecurity controls verbeteren.<\/p>\n\n\n\n

    Heeft u een security baseline nodig voordat u een volledige NIS2 penetration test laat uitvoeren? Start met CyberCheck<\/a><\/strong> als uw team nog niet zeker weet welke systemen het meeste risico dragen, welke gaps eerst moeten worden hersteld of welk bewijs al ontbreekt.<\/p>\n\n\n\n

    Wat een NIS2-compliant pentest report moet bevatten<\/h2>\n\n\n\n

    Een NIS2-ready penetration test report moet meer doen dan kwetsbaarheden opsommen. Het moet bewijs opleveren dat Artikel 21-risk management, interne governance, customer due diligence en remediation planning ondersteunt.<\/p>\n\n\n\n

    Een sterk rapport bevat zeven onderdelen.<\/p>\n\n\n\n

    \"07
    07 elementen van een NIS2-conform penetratietest-rapport<\/figcaption><\/figure>\n\n\n\n

    1. Scope statement<\/h3>\n\n\n\n

    Het rapport moet aangeven wat wel en niet is getest. Dit omvat systemen, applicaties, APIs, IP ranges, user roles, environments, leveranciers en testbeperkingen.<\/p>\n\n\n\n

    Out-of-scope systems tellen. Als een kritieke payment API of identity provider is uitgesloten, moet het rapport dat benoemen. Anders kan management aannemen dat er dekking is die de test niet heeft geleverd.<\/p>\n\n\n\n

    2. Methodology used<\/h3>\n\n\n\n

    Het rapport moet de testing methodology of het framework benoemen. Voor Nederlandse organisaties kan MIAUW worden gebruikt als referentie voor testing met auditwaarde. Voor application testing kunnen OWASP WSTG of OWASP API Security Testing guidance ook relevant zijn.<\/p>\n\n\n\n

    De methodology section mag niet decoratief zijn. Deze moet uitleggen hoe testing is gepland, uitgevoerd en gedocumenteerd.<\/p>\n\n\n\n

    3. Findings with severity scoring<\/h3>\n\n\n\n

    Elke finding moet severity, affected asset, exploit conditions en business impact bevatten. CVSS kan helpen om technische severity te standaardiseren, maar het rapport moet ook business priority uitleggen.<\/p>\n\n\n\n

    Een medium technical finding kan high priority worden als deze een public system, critical supplier connection of sensitive data flow raakt.<\/p>\n\n\n\n

    4. Exploitation evidence<\/h3>\n\n\n\n

    Voor Artikel 21(2)(f) is dit het belangrijkste deel van het rapport. De organisatie heeft bewijs nodig dat laat zien of controles werkten.<\/p>\n\n\n\n

    Bruikbaar bewijs kan bestaan uit screenshots, logs, request\/response examples, proof-of-concept steps, affected user roles, access paths of attack chain diagrams. Gevoelig bewijs moet zorgvuldig worden behandeld en onder access control worden opgeslagen.<\/p>\n\n\n\n

    5. Remediation recommendations<\/h3>\n\n\n\n

    Een goed rapport vertelt het team wat eerst moet worden hersteld. Findings moeten worden gegroepeerd op severity, exploitability en business impact.<\/p>\n\n\n\n

    Het remediation-overzicht moet specifiek genoeg zijn voor engineering-, infrastructure-, security- en managementteams om owners toe te wijzen. \u201cFix access control\u201d is niet genoeg. \u201cRestrict role X from endpoint Y and add server-side authorisation check before release Z\u201d is actiegericht.<\/p>\n\n\n\n

    6. Retest results<\/h3>\n\n\n\n

    Retesting sluit de bewijsloop. Zonder retest results kan de organisatie laten zien dat een finding is gerapporteerd, maar niet dat deze is hersteld.<\/p>\n\n\n\n

    Voor NIS2-bewijs bewaart u de oorspronkelijke finding, remediation action, owner, target date en retest result samen. Critical en high findings mogen niet open blijven staan als tickets zonder einddatum en zonder gedocumenteerd besluit.<\/p>\n\n\n\n

    7. Executive summary<\/h3>\n\n\n\n

    Het rapport moet een management summary bevatten die risico uitlegt in zakelijke termen. Deze moet benoemen wat is getest, wat de belangrijkste findings waren, wat open blijft en welk besluit management moet nemen.<\/p>\n\n\n\n

    Deze summary kan ook Artikel 20 governance evidence ondersteunen, omdat management bodies genoeg informatie nodig hebben om toezicht te houden op cybersecurityrisico. Voor leiderschapsverantwoordelijkheden buiten het test report: zie hoe NIS2 Article 20 management accountability<\/a><\/strong> security evidence koppelt aan board-level oversight.<\/p>\n\n\n\n

    Deze records moeten in het bredere NIS2 evidence pack<\/a><\/strong> worden opgenomen, samen met risk decisions, remediation tracking en management approval records.<\/p>\n\n\n\n

    NCSC guidance voor Nederlandse NIS2-entiteiten<\/h2>\n\n\n\n

    Voor Nederlandse organisaties is de Cyberbeveiligingswet de nationale implementatieroute voor NIS2. Op het moment van publicatie op 29 mei 2026 had de Tweede Kamer de Cyberbeveiligingswet goedgekeurd en zat het voorstel in het proces bij de Eerste Kamer. Nederlandse overheidsbronnen adviseerden organisaties om niet te wachten tot de wet in werking treedt voordat zij zich voorbereiden.<\/p>\n\n\n\n

    Die timing be\u00efnvloedt hoe dit artikel gelezen moet worden. Nederlandse entiteiten moeten penetration testing niet behandelen als een last-minute auditactiviteit. Een praktische manier om die last-minute druk te vermijden is eerst een NIS2 gap analysis<\/a><\/strong> uitvoeren en de resultaten daarna gebruiken om te bepalen welke systemen scanning, DAST, penetration testing of supplier evidence nodig hebben. De test cre\u00ebert alleen waarde als er genoeg tijd is om findings te herstellen en critical issues opnieuw te testen v\u00f3\u00f3r customer due diligence, supervisory review of board reporting.<\/p>\n\n\n\n

    De expertblog van NCSC over penetration testing wijst ook op een praktisch probleem: penetration testing kan in verschillende contexten verschillende dingen betekenen. Zonder duidelijke scoping- en rapportageverwachtingen kan een test moeilijk vergelijkbaar, moeilijk te auditen en moeilijk bruikbaar worden voor managementbesluiten.<\/p>\n\n\n\n

    MIAUW is relevant in die Nederlandse context omdat het een meer gestructureerde manier biedt om penetration testing in te kopen en te documenteren. Voor NIS2-voorbereiding is die structuur het punt. De organisatie heeft bewijs nodig dat later kan worden gereviewd, niet alleen technische findings die in een PDF blijven staan.<\/p>\n\n\n\n

    Hoe Sunbytes NIS2-compliant vulnerability testing levert<\/h2>\n\n\n\n

    Sunbytes<\/a><\/strong> helpt EU-bedrijven om van een onduidelijke security posture naar evidence-backed remediation te gaan. Voor NIS2 penetration testing is de eerste stap vaak geen full-scope test. Het is een baseline: welke systemen tellen, welke risico\u2019s zijn al bekend, welk bewijs bestaat en welke gaps moeten eerst worden hersteld.<\/p>\n\n\n\n

    Daar past CyberCheck. CyberCheck is een baseline + gap + roadmap assessment. Het helpt teams hun huidige security posture te begrijpen, prioriteitsgaps te identificeren en te bepalen wat diepere testing nodig heeft. Het helpt te bepalen waar een penetration test zich op moet richten en welk bewijs de organisatie moet voorbereiden.<\/p>\n\n\n\n

    Why Sunbytes?<\/h3>\n\n\n\n

    Sunbytes is een Nederlands technologiebedrijf met hoofdkantoor in Nederland en een delivery hub in Vietnam. Al 15 jaar helpen wij klanten wereldwijd met Transform \u00b7 Secure \u00b7 Accelerate \u2014 strategie omzetten in betrouwbare delivery, met security ingebouwd in de manier waarop systemen worden ontworpen, getest en onderhouden.<\/p>\n\n\n\n