Onder de NIS2-richtlijn is Artikel 21 het punt waarop “we nemen beveiliging serieus” verandert in “bewijs het”. De vereisten van Artikel 21 bepalen de minimale cybersecurityrisicobeheersmaatregelen die organisaties binnen scope moeten implementeren en in de praktijk moeten kunnen aantonen.
EU-lidstaten kunnen verschillen in hoe zij NIS2 omzetten naar nationaal recht, maar de bedoeling van Artikel 21 is consistent: risicogebaseerde, proportionele controls, ondersteund door operationeel bewijs.
Deze gids vertaalt Artikel 21 naar praktische acties, voorbeelden van bewijs en een Minimum Viable Evidence Pack dat mkb-organisaties kunnen opbouwen zonder te over-engineeren.
TL;DR
NIS2 Artikel 21 vereist dat organisaties binnen scope passende en proportionele cybersecurityrisicobeheersmaatregelen implementeren en aantonen dat deze in de praktijk werken. Het artikel behandelt 10 verplichte gebieden: risico, incidenten, continuïteit, supply chain, veilige ontwikkeling, testen, training, crypto, toegangs-/HR-beveiliging en MFA/veilige communicatie. Readiness betekent drie dingen: eigenaarschap, bewijs en een verbetercyclus. Gebruik de NIS2 Artikel 21 Readiness Assessment hieronder om uw huidige controls te scoren en de gaps te identificeren die eerst aandacht nodig hebben.
Wilt u gestructureerde ondersteuning, dan helpt Sunbytes Compliance Readiness u bij het opbouwen van een evidence pack en een geprioriteerde remediation-roadmap die aansluit op Artikel 21.
Update Nederland: status Cyberbeveiligingswet in juni 2026
Voor Nederlandse organisaties wordt NIS2 omgezet via de Cyberbeveiligingswet (Cbw). Per juni 2026 moet de wet nog niet worden beschreven als volledig van kracht: de Tweede Kamer nam het voorstel aan op 15 april 2026, en het voorstel was in juni 2026 nog in behandeling bij de Eerste Kamer.
De NCTV vermeldt dat de Eerste Kamer haar verslag op 2 juni 2026 uitbracht, dat de regering de gestelde vragen heeft beantwoord en dat de plenaire behandeling vervolgens werd verwacht. Totdat de Cyberbeveiligingswet in werking treedt, stelt NCTV dat er geen directe NIS2- of CER-verplichtingen voor organisaties gelden onder de Nederlandse implementatiewet, hoewel bepaalde rechten al kunnen gelden door rechtstreekse werking van sommige NIS2-bepalingen. De praktische implicatie is eenvoudig: claim nog geen definitieve compliance onder Nederlands recht, maar begin nu wel met het opbouwen van controlbewijs voor Artikel 21.
Wat vereist NIS2 Artikel 21?
Artikel 21 vereist “passende en proportionele” cybersecurityrisicobeheersmaatregelen en het vermogen om aan te tonen dat die maatregelen in de praktijk werken. Zie ook de officiële tekst van de NIS2-richtlijn.
In gewone taal wordt van u verwacht dat u laat zien dat beveiliging als een herhaalbaar proces wordt beheerd:
- Risico’s worden geïdentificeerd en geprioriteerd
- Controls worden geïmplementeerd en hebben een eigenaar
- Controls worden gemonitord en beoordeeld
- Beslissingen worden gedocumenteerd, inclusief trade-offs
- Bewijs kan snel worden geleverd wanneer daarom wordt gevraagd
De 3 principes achter Artikel 21, zodat u niet over-engineert
NIS2 Artikel 21 is bewust resultaatgericht. In plaats van specifieke technologieën of frameworks voor te schrijven, definieert het artikel hoe organisaties moeten nadenken over cybersecurityrisico’s, hoe zij die risico’s beheren en hoe zij bewijs leveren. Drie principes liggen onder elke control in Artikel 21, en inzicht in deze principes helpt over-engineering te voorkomen.
Risicogebaseerd, niet checklist-gedreven
Artikel 21 verwacht dat beslissingen worden gestuurd door uw werkelijke dreigingen en zakelijke impact, niet door generieke templates. U moet kunnen uitleggen waarom u voor een bepaald controlniveau koos, of waarom u niet simpelweg een template kopieerde.
Beveiliging strekt zich uit tot uw supply chain
U bent verantwoordelijk voor risico’s die worden geïntroduceerd door leveranciers en dienstverleners, vooral wanneer zij kritieke diensten ondersteunen. Dit is vaak waar mkb-organisaties worden verrast.
Bewijs is belangrijker dan intentie
Toezichthouders en kopers vragen niet wat u van plan was te doen. Zij vragen wat u kunt aantonen: logs, tickets, testresultaten, trainingsvoltooiing en reviewnotities.
Wat zijn de 10 verplichte cybersecurityrisicobeheersmaatregelen in Artikel 21?
Artikel 21 definieert tien minimale gebieden die u moet afdekken. Het doel is niet “perfecte volwassenheid”, maar een verdedigbare basislijn die eigenaar heeft, gedocumenteerd is en werkt.
| Maatregelgebied | Hoe “goed genoeg” eruitziet (mkb-basislijn) | Bewijsvoorbeelden die kopers/toezichthouders controleren |
|---|---|---|
| 1) Risicoanalyse & beveiligingsbeleid | Documenteer toprisico’s + overeengekomen behandeling | Risicoregister, beleidsgoedkeuring, assetinventaris |
| 2) Incidentafhandeling | U kunt detecteren, reageren en leren | IR-plan, escalatiematrix, incidenttickets, PIR-template |
| 3) Business continuity & crisismanagement | U kunt diensten herstellen | Back-upbeleid, restoretestresultaten, RTO/RPO, DR-runbook |
| 4) Supply chain security | U kent uw kritieke leveranciers en verwachtingen | Leveranciersinventaris, securityclausules, reviewchecklist, communicatieproces |
| 5) Veilige aankoop/ontwikkeling/onderhoud | Security is ingebed in change en patching | SDLC-gates, changerecords, patch-SLA’s, vulnerabilityproces |
| 6) Effectiviteitstesten | Controls worden getest en verbeterd | Scan-/pentest-samenvatting, KPI-dashboard, actietracker |
| 7) Cyberhygiëne & training | Mensen kennen basisgedrag rond cybersecurity | Trainingsmateriaal, voltooiingsrecords, onboarding-/offboardingchecklist |
| 8) Cryptografie/encryptie | Data wordt beschermd waar dat ertoe doet | Encryptiebeleid, configuraties, TLS-instellingen, key-aanpak |
| 9) Toegangsbeheer, assetmanagement, HR-beveiliging | Toegang wordt lifecycle-gestuurd beheerd | JML-proces, toegangsreviews, assetinventaris, baselineconfiguraties |
| 10) MFA & veilige communicatie | MFA op kritieke toegang + fallbackcommunicatie | MFA-configuratiebewijs, adminhardening, noodcommunicatiedrill |
NIS2 Artikel 21 Readiness Assessment
Gebruik deze self-assessment met 10 vragen om Artikel 21 om te zetten in een eerste gaplijst. Dit is geen juridisch advies en geen formele audit. Het is een praktische manier om te zien of uw huidige controls gedocumenteerd zijn, een eigenaar hebben en door bewijs worden ondersteund.
NIS2 Artikel 21 Readiness Assessment
Beantwoord elke vraag op basis van wat u vandaag kunt aantonen, niet op basis van wat gepland is.
Gebruik deze output als startpunt voor een interne readiness-discussie. Stem de uitkomst voor een formeel standpunt af op uw nationale implementatieregels, sectorrichtlijnen en juridisch advies.
Als de assessment meerdere antwoorden “Deels” of “Nee” oplevert, behandel dit dan als een prioriteringssignaal. De volgende stap is niet meer beleid schrijven. De volgende stap is bevestigen welke gaps het hoogste operationele of compliancerisico creëren, eigenaren toewijzen en ze omzetten in een remediation-plan.
Maatregel voor maatregel: wat het betekent en welk bewijs u moet voorbereiden
Risicoanalyse & beveiligingsbeleid
U moet cybersecurityrisico’s voor kritieke systemen/diensten identificeren en definiëren hoe ze worden beheerd. Bewijs moet laten zien dat risico’s geprioriteerd en gereviewd worden, niet alleen beschreven.
Bewijsvoorbeelden: risicobeoordelingsrapport, risicoregister, beveiligingsbeleid (goedgekeurd), asset-/service-inventaris, reviewnotities.
Incidentafhandeling
U heeft een werkbaar incidentresponsproces nodig: rollen, escalatie, acties en leerloops. Toezichthouders kijken naar voorbereidheid: kan uw team het daadwerkelijk uitvoeren?
Bewijsvoorbeelden: IR-plan, escalatiematrix, incidentlog/tickets, template voor post-incident review, tabletop-notities.
Business continuity & crisismanagement
U moet de beschikbaarheid van diensten tijdens en na incidenten behouden. Back-ups die “draaien” zijn niet genoeg — restoretesten is de geloofwaardigheidsmarker.
Bewijsvoorbeelden: back-upbeleid, restoretestresultaten, RTO/RPO-definities, DR-runbook, crisiscommunicatieplan.
Supply chain security
U moet third-party risks beheren. Voor mkb-organisaties brengt een eenvoudige leveranciersinventaris + criticality rating + basisverwachtingen al veel duidelijkheid.
Bewijsvoorbeelden: leverancierslijst met criticality, security-addendum/clausules, vendor review checklist, incidentcommunicatieprocedure.
Veilige systeemverwerving, ontwikkeling en onderhoud
Security moet onderdeel zijn van hoe u systemen koopt, bouwt, wijzigt en patcht, niet iets dat later wordt toegevoegd. Mkb-organisaties hebben geen zware bureaucratie nodig, maar wel herhaalbare gates.
Bewijsvoorbeelden: secure SDLC-notities, changemanagementrecords, patchbeleid + SLA’s, vulnerability intake/disclosure channel.
Effectiviteitstesten van cybersecuritymaatregelen
U moet verifiëren dat controls daadwerkelijk werken. De nadruk ligt op verbetering in de tijd, niet op constante pentests overal.
Bewijsvoorbeelden: scan-/pentest-samenvattingen, interne reviewnotities, KPI-dashboard (MFA-dekking, patch-SLA, restoretests), actietracker.
Cyberhygiëne en medewerkerstraining
Awareness moet consistent en rolgericht zijn. Het bewijs is eenvoudig: materialen + aanwezigheid + onboarding-/offboardingstappen.
Bewijsvoorbeelden: trainingscontent, voltooiingslogs, phishing-simulatierapport (optioneel), JML-checklist.
Cryptografie en encryptie
Gebruik waar passend cryptografie om vertrouwelijkheid en integriteit te beschermen, vooral voor gevoelige data en adminverkeer.
Bewijsvoorbeelden: encryptiebeleid, TLS-instellingen, bewijs van encryptie-at-rest, key management-aanpak (op hoofdlijnen).
Toegangsbeheer, assetmanagement en HR-beveiliging
Dit gaat over lifecycle-control: least privilege + joiner/mover/leaver-discipline + assetzichtbaarheid.
Bewijsvoorbeelden: toegangsreviewlogs, JML-proces, assetinventaris, endpoint-baseline-instellingen.
Multi-factor authentication en veilige communicatie
MFA op kritieke systemen en admintoegang is een basisverwachting. Definieer ook veilige kanalen en noodcommunicatie.
Bewijsvoorbeelden: screenshots/configuraties van MFA-afdwinging, adminhardening, break-glass-controls, notities van noodcommunicatiedrills.
“Minimum Viable Evidence Pack” voor mkb onder NIS2 Artikel 21
Voor mkb-organisaties draait de vereiste van NIS2 Artikel 21 om het vermogen om control op een geloofwaardige, proportionele manier aan te tonen. Een Minimum Viable Evidence Pack is een gerichte set policies, records en technisch bewijs die samen laten zien dat u de vereiste cybersecurityrisicobeheersmaatregelen heeft geïmplementeerd, uitgevoerd en gereviewd.
Voordat veel mkb-organisaties een volledig evidence pack voor Artikel 21 bouwen, hebben zij eerst een security baseline nodig: welke controls werken al, welke gaps vragen remediation en welke acties moeten naar de komende 30/60/90 dagen. Sunbytes CyberCheck ondersteunt dat startpunt door uw huidige posture te beoordelen en bevindingen om te zetten in een praktische remediation-roadmap.
Governance & Risk
Cybersecurity Risk Assessment Report
Identificeert de meest relevante cybersecurityrisico’s voor systemen en diensten en prioriteert ze op basis van impact en waarschijnlijkheid. Laat zien dat securitybeslissingen risicogebaseerd zijn in plaats van generiek.
Information Security Policy (door management goedgekeurd)
Definieert securitydoelen, rollen en principes, met duidelijke managementgoedkeuring. Toont accountability en governance op directieniveau.
Risk Treatment of Remediation Plan
Koppelt geïdentificeerde risico’s aan mitigerende acties, eigenaren en timelines. Laat zien dat risico’s actief worden beheerd, niet alleen gedocumenteerd.
Asset Inventory (systemen & data)
Lijst kritieke systemen, diensten en datatypes op. Vormt de basis voor toegangsbeheer, risicoanalyse en incidentrespons.
Incident & Continuity Readiness
Incident Response Plan (met NIS2-rapportageafstemming)
Definieert hoe incidenten worden gedetecteerd, geëscaleerd, beheerd en opgelost, inclusief beslisrollen en rapportagetriggers.
Incident Log of Incident Report Template
Biedt een gestructureerde manier om incidenten, root causes en lessons learned te documenteren. Kan records bevatten van tests of tabletop-oefeningen.
Business Continuity / Back-upbewijs
Laat zien dat back-ups bestaan en hersteld kunnen worden. Bevat meestal back-upbeleid en recente restoretestresultaten.
Technische & operationele controls
Access Control & MFA Evidence
Toont aan dat toegang tot kritieke systemen is beperkt en beschermd met multi-factor authentication. Screenshots of configuratierecords zijn voor mkb-organisaties meestal voldoende.
Patch & Vulnerability Management Records
Laat zien hoe kwetsbaarheden en patches worden geïdentificeerd, geprioriteerd en toegepast. Bevat policies en voorbeeldlogs of scanresultaten.
Secure Configuration of Hardening Evidence
Documenteert baseline beveiligingsconfiguraties voor systemen of endpoints. Tooloutputs of screenshots zijn acceptabel voor mkb-organisaties.
Encryption of Data Protection Evidence
Legt uit waar encryptie wordt toegepast (in transit en/of at rest) en waarom. Ondersteund door beleid en configuratievoorbeelden.
Penetration Test of Security Assessment Summary
Biedt bewijs dat securitycontrols op effectiviteit worden getest. Een executive-level samenvatting is voldoende.
Mensen & awareness
Cybersecurity Awareness Training Materials
Slides, video’s of content uit een leerplatform laten zien dat medewerkers richtlijnen krijgen over basis-cyberrisico’s en verwacht gedrag.
Training Attendance Records
Deelnemerslijsten en voltooiingsdatums tonen aan dat training wordt geleverd en afgerond, met datums en deelnemers vastgelegd.
Joiner / Mover / Leaver Access Checklist
Bevestigt dat toegangsrechten consistent worden toegekend, gewijzigd en ingetrokken gedurende de volledige employee lifecycle.
Wilt u begrijpen hoe deze bewijsvereisten uit Artikel 21 passen binnen uw bredere NIS2-verplichtingen, lees dan onze NIS2 compliance checklist: 40 controles die EU-bedrijven kunnen gebruiken voor een gestructureerd end-to-end overzicht van wat u daarna moet doen.
Drie veelvoorkomende gaps in Artikel 21-readiness
Controls bestaan, maar zijn niet gedocumenteerd
Securitymaatregelen worden vaak informeel geïmplementeerd: MFA staat aan, back-ups draaien, toegang is beperkt, maar niets is vastgelegd. Zonder documentatie zijn deze controls moeilijk uit te leggen, te reviewen of te verdedigen. Toezichthouders beoordelen wat kan worden aangetoond, niet wat wordt verondersteld te bestaan.
Leveranciersrisico’s zijn niet beoordeeld
Veel organisaties leunen zwaar op derde partijen, maar hebben weinig zicht op welke leveranciers kritiek zijn of hoe hun risico’s worden beheerd. Contracten zeggen soms niets over security, en incidentscenario’s met leveranciers worden zelden meegenomen. Onder Artikel 21 is dit een duidelijke en terugkerende zwakte.
Geen bewijs van effectiviteitstesten
Zelfs wanneer controls bestaan en gedocumenteerd zijn, kunnen organisaties vaak niet laten zien dat ze werken. Back-ups zijn niet getest, incidentplannen zijn niet geoefend en kwetsbaarheden worden niet systematisch gereviewd. Artikel 21 verwacht bewijs van testen, review en verbetering — geen statische controls.
Voorbereiden op Artikel 21 zonder over-engineering
NIS2 Artikel 21 verwacht niet dat mkb-organisaties enterprise-grade securityprogramma’s bouwen. Het vereist expliciet passende en proportionele maatregelen, rekening houdend met risicoblootstelling, omvang en implementatiekosten. De uitdaging voor de meeste organisaties is hoe u precies genoeg doet — en niet meer — terwijl het nog steeds verdedigbaar blijft.
Een praktische manier om dit aan te pakken is Artikel 21 te vertalen naar vier eenvoudige vragen voor elke vereiste maatregel:
- Wat moeten we implementeren?
- Hoe bewijzen we het?
- Wie is eigenaar?
- Hoeveel inspanning kost het realistisch?
Een praktische mapping: maatregel → bewijs → eigenaar → inspanning
Deze mapping verandert Artikel 21 van juridische tekst in een operationele roadmap.
- Maatregel: wat Artikel 21(2)(a)–(j) expliciet vereist dat u adresseert.
- Bewijs: wat toezichthouders, auditors of klanten redelijkerwijs kunnen controleren om te bevestigen dat de maatregel is geïmplementeerd en werkt.
- Eigenaar: de persoon die verantwoordelijk is voor het onderhouden van de maatregel en het bewijs. In mkb-organisaties is dit vaak één persoon met meerdere petten, bijvoorbeeld een IT Manager die ook Security Lead is.
- Typische inspanning: een realistische inschatting van het werk dat nodig is om een verdedigbare basislijn te bereiken, niet theoretische volwassenheid.
Deze aanpak zorgt ervoor dat elke vereiste een duidelijk doel, bewijs en accountable owner heeft, waardoor duplicatie en onnodig werk worden verminderd.
De inspanningsschaal begrijpen (mkb-reality check)
Om over-engineering te voorkomen, moet inspanning consistent worden beoordeeld:
- S (Small): 1–5 werkdagen
Vooral documentatie, lichte configuratie of het formaliseren van wat al bestaat. - M (Medium): 2–6 weken
Procesdefinitie, toolingverbeteringen, evidence setup en basistesten. - L (Large): 6–12+ weken
Cross-team coördinatie, architectuurwijzigingen, nieuwe tooling of herhaalde testcycli.
Voor de meeste mkb-organisaties valt het grootste deel van de Artikel 21-maatregelen in Small of Medium wanneer ze pragmatisch worden aangepakt.
| Maatregel (Artikel 21(2)) | Bewijs (wat auditors/kopers kunnen controleren) | Eigenaar (typisch mkb) | Typische inspanning |
|---|---|---|---|
| (a) Beleid voor risicoanalyse & beveiliging van informatiesystemen | Risicoregister (toprisico’s + behandeling); set beveiligingsbeleid; asset-/service-inventaris; periodieke risicoreviewnotities | Security Lead / IT Manager + CTO-sponsor | M |
| (b) Incidentafhandeling | Incidentresponsplan + rollen; escalatiematrix; incidentticketrecords; post-incident review-template; on-callproces | Security Lead + Engineering Lead | M |
| (c) Business continuity (back-up/DR) & crisismanagement | Back-upbeleid; restoretestresultaten; RTO/RPO-doelen; DR-runbook; crisiscommunicatieplan | IT Ops / Platform Lead | M–L (afhankelijk van systemen) |
| (d) Supply chain security (directe leveranciers/providers) | Leveranciersinventaris + criticality; securityclausules in contracten; vendor review checklist; gevolgde bewijsverzoeken; third-party incidentcommunicatieproces | Procurement/Operations + Security Lead | M |
| (e) Security in systeemverwerving, ontwikkeling en onderhoud | SDLC/security-gates; changemanagementrecords; vulnerability management-procedure; patch-SLA’s; vulnerability disclosure/contact channel | Engineering Lead + AppSec / Security Lead | M–L |
| (f) Effectiviteit van maatregelen beoordelen (testen/meten) | KPI-dashboard (patch-SLA, MFA-dekking, back-uptests); interne audits; pentest/scans indien gebruikt; actietracker | Security Lead + CTO | S–M |
| (g) Basis cyberhygiëne & cybersecuritytraining | Security awareness policy; trainingsvoltooiingsrecords; phishing-simulaties (optioneel); onboarding-/offboardingchecklist | HR/People Ops + Security Lead | S–M |
| (h) Cryptografie & encryptie (waar passend) | Encryptie-at-rest/in-transit-instellingen; key management-aanpak; TLS-configs; dataclassificatie + “wat moet worden versleuteld” | IT Ops / Platform Lead | S–M |
| (i) HR-beveiliging, toegangsbeheerbeleid & assetmanagement | Joiner-Mover-Leaver-proces; toegangsreviewlogs; least-privilegebeleid; assetinventaris; endpoint baseline | IT Manager + HR | M |
| (j) MFA/continuous authentication + beveiligde communicatie + noodcommunicatie (waar passend) | MFA afgedwongen voor kernsystemen; hardening van admintoegang; beleid voor veilige communicatietools; break-glass-accounts; noodkanaaldrill | IT Manager / Security Lead | S–M |
Hoe Sunbytes NIS2 Artikel 21 Compliance Readiness ondersteunt
Sunbytes hanteert een evidence-first, regulator-aligned aanpak voor NIS2 Artikel 21-readiness. We focussen op wat autoriteiten, auditors en klanten daadwerkelijk vragen: duidelijke risicoredenering, operationeel bewijs en realistische prioritering. Ons Secure by Design-werk brengt beleid, controls, technische remediation en bewijsstructuur samen, zodat teams compliancewerk kunnen uitvoeren zonder delivery onnodig te vertragen.
Weet u niet zeker waar de echte gaps zitten, start dan met Sunbytes CyberCheck om een baseline en remediation-roadmap vast te stellen. Kent u de gaps al en moet u audit-ready bewijs opbouwen, dan richt Sunbytes Compliance Readiness zich op evidence packs, controle-eigenaarschap en geprioriteerde remediation die is afgestemd op de vereisten van NIS2 Artikel 21.
Wilt u weten of u moet starten met een baseline-assessment of direct met evidence pack-opbouw?
Voor Nederlandse lezers: wat veranderde er in juni 2026?
De belangrijkste verandering is duidelijkheid over timing. De Cyberbeveiligingswet was aangenomen door de Tweede Kamer en was in juni 2026 nog in behandeling bij de Eerste Kamer. Dat betekent dat Nederlandse organisaties voorzichtig moeten zijn met claims over definitieve compliance onder de Cbw, maar niet moeten wachten met voorbereiding. Artikel 21-bewijs — risicoanalyse, incidentrespons, business continuity, supply chain security, access control, MFA en testrecords — blijft het praktische fundament om readiness aan te tonen zodra nationale verplichtingen van kracht worden.
FAQs
Niet per se “perfect”, maar streef ernaar om alle 10 meetgebieden op een basisniveau te dekken, omdat artikel 21(2) ze als minimumgebieden noemt.
Een praktische aanpak voor mkb’s:
Week 1-2: bepaal verantwoordelijkheden + minimale beleidsregels + structuur voor bewijsmateriaal
Week 3-6: implementeer de beheersmaatregelen met het hoogste risico (MFA, back-up-/hersteltesten, afhandeling van kwetsbaarheden)
Doorlopend: verbeter de volwassenheid met meetbare KPI’s en periodieke evaluaties
NIS2 omschrijft maatregelen duidelijk als “passend en proportioneel” en benadrukt factoren zoals de stand van de techniek, relevante normen, implementatiekosten, uw risicoblootstelling, omvang en potentiële impact van incidenten.
In de praktijk betekent “proportioneel” meestal:
U kunt rechtvaardigen waarom een maatregel op een bepaalde manier wordt geïmplementeerd (risicogebaseerd)
U hebt bewijs dat de maatregel werkt (niet alleen een beleidsdocument)
U geeft prioriteit aan beheersmaatregelen die waarschijnlijke/risico’s met grote impact verminderen
ISO 27001 kan veel helpen, maar de gereedheid voor NIS2 hangt nog steeds af van de reikwijdte, de specifieke verplichtingen en het bewijs van operationele ervaring. NIS2 legt ook de nadruk op termijnen voor incidentrapportage (artikel 23) en praktijken in de toeleveringsketen. Beschouw ISO als een solide basis en valideer vervolgens eventuele tekortkomingen aan de hand van artikel 21/23 en lokale implementatieregels.
Een beleid beschrijft de intentie. Bewijs toont aan dat de controle daadwerkelijk en herhaalbaar is.
Voorbeeld: “We maken back-ups” (beleid) versus testresultaten van het herstelproces + RTO/RPO + runbook + de laatste 3 testtickets (bewijs). Bewijslevering is vaak het eerste waar inkoopteams en auditors naar vragen.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
