Waarom dit artikel bestaat
Steeds meer opdrachtgevers vragen ons om aantoonbaar te maken hoe wij omgaan met de eisen die voortvloeien uit de Europese NIS2-richtlijn (2022/2555) en de Nederlandse implementatie via de Cyberbeveiligingswet (Cbw). Dat is logisch: NIS2 Artikel 21 lid 2 sub d verplicht hen om de beveiligingsrisico's in hun toeleveringsketen aantoonbaar te beheersen — en als wij voor hen software bouwen of beheren, zijn wij onderdeel van die keten.
Coding Agency valt zelf niet onder NIS2 (eenmanszaak, 1 fte, onder de grenswaarden), maar onze klanten dus wél. Daarom hebben wij onze aanpak inhoudelijk afgestemd op NIS2 Artikel 21 en kunnen wij opdrachtgevers ondersteunen met de documentatie en bewijsstukken die zij nodig hebben.
NIS2 kent geen certificering voor leveranciers. Wat wel telt: aantoonbare maatregelen, contractuele afspraken en eerlijke transparantie over wat we wel en niet kunnen waarmaken.
Mapping op NIS2 Artikel 21 lid 2
Artikel 21 lid 2 van de NIS2-richtlijn somt tien risicobeheersmaatregelen op die elke entiteit minimaal moet implementeren. Hieronder per onderdeel hoe wij dat invullen.
a) Beleid voor risicoanalyse en informatiesysteembeveiliging
We hanteren een Information Security Management System (ISMS) conform ISO/IEC 27001:2022. Dat omvat een formeel scope statement (DOC-001), een informatiebeveiligingsbeleid (DOC-002), een Statement of Applicability (DOC-003) en een risicoregister dat jaarlijks wordt herzien. Op verzoek beschikbaar onder NDA.
b) Incidentbehandeling
Vaste procedure met detectie via realtime monitoring, inperking, herstel en lessons learned. De volledige tijdlijn — inclusief de getrapte meldplicht uit NIS2 Artikel 23 — staat op onze security & vertrouwen-pagina.
c) Bedrijfscontinuïteit, back-upbeheer, crisisbeheersing
Dagelijkse versleutelde back-ups buiten piekuren, retentie van minimaal 30 dagen, geografisch redundant binnen de EU. Restore-procedure wordt periodiek getest. Voor opdrachtgevers met hogere RTO/RPO-eisen maken we maatwerk-afspraken in het service level.
d) Beveiliging van de toeleveringsketen
Volledig en publiek inzichtelijk subverwerkersregister op de security-pagina. Met elke partij is een verwerkersovereenkomst (DPA) gesloten conform AVG Artikel 28. We delen geen persoonsgegevens met derden voor commerciële of marketingdoeleinden. Subverwerkers worden jaarlijks geëvalueerd.
e) Beveiliging bij verwerving, ontwikkeling en onderhoud van systemen
Privé Git-repositories op Europese infrastructuur, geautomatiseerde dependency scanning op CVE's, verplichte code review vóór deploy, geautomatiseerde testsuites en security-headers (CSP, HSTS, X-Frame-Options) als baseline. Voor diepere achtergrond zie ons artikel security by design in Laravel.
f) Beleid en procedures om de doeltreffendheid van maatregelen te beoordelen
Evaluatie van maatregelen vindt plaats bij elk significant incident, bij wijzigingen aan de scope en bij relevante updates van wet- en regelgeving. Het risicoregister wordt herzien zodra de aanleiding daartoe ontstaat. Voor opdrachtgevers met formelere review-eisen kan het ritme contractueel worden vastgelegd.
g) Basismaatregelen op het gebied van cyberhygiëne en training
Least privilege als uitgangspunt op elk systeem en elke service. Hardening van workstations (FileVault, automatische updates, screen-lock), security awareness en monitoring van phishing-pogingen. Bij inzet van freelancers wordt een NDA en security-briefing verplicht gesteld.
h) Beleid en procedures voor cryptografie
TLS 1.2 of 1.3 voor alle verbindingen (HSTS verplicht, automatische redirect HTTP→HTTPS), encryptie at rest op zowel schijfniveau (LUKS/AWS KMS) als applicatieniveau voor gevoelige velden, bcrypt met hoge cost-factor voor wachtwoord-hashing. Sleutelbeheer via beheerde KMS-services.
i) Beveiliging van personele middelen, toegangsbeheer en activabeheer
SSH key-only toegang tot servers (geen wachtwoord-authenticatie), gescheiden productie- en development-omgevingen, gelogde beheer-toegang met retentie. Bij vertrek van een freelancer wordt toegang per direct ingetrokken en gerouleerd.
j) Multi-factor authenticatie en versleutelde communicatie
MFA verplicht op alle beheeraccounts, cloud-consoles (AWS, DigitalOcean, Hetzner) en kritieke systemen. Interne en externe e-mail loopt via Proton Mail (end-to-end versleuteld waar mogelijk). Voor real-time communicatie met opdrachtgevers gebruiken we waar gewenst Signal of versleutelde alternatieven.
Incidentmelding: NIS2 Artikel 23 in de praktijk
NIS2 Artikel 23 introduceert een driestapsmelding voor significante incidenten. Onze procedure ondersteunt opdrachtgevers in elk van die stappen:
- Binnen 24 uur — early warning aan het CSIRT (in NL: NCSC of sectorale CSIRT). Wij signaleren het incident, bepalen samen of het significant is, en helpen de melding voor te bereiden.
- Binnen 72 uur — formele incidentnotificatie. We leveren technische details, getroffen systemen, eerste impact-analyse en mitigerende maatregelen aan zodat de opdrachtgever de notificatie kan indienen. Parallel wordt — als het ook een datalek betreft — gemeld bij de Autoriteit Persoonsgegevens conform AVG Artikel 33.
- Binnen 1 maand — eindrapport. Root-cause-analyse, getroffen mitigaties, eventuele grensoverschrijdende impact en lessons learned. Wij leveren onze bijdrage aan dit rapport in het door de opdrachtgever gewenste formaat.
Wat u van ons krijgt
Voor opdrachtgevers die onder NIS2 of de Cbw vallen, leveren wij standaard:
- Vendor security questionnaire — wij vullen jouw eigen format in, of leveren onze standaard antwoorden.
- NIS2-supplier statement — een document met directe mapping op Artikel 21, geschikt voor jouw audit-trail.
- Verwerkersovereenkomst (DPA) — conform AVG Artikel 28, voor zover wij persoonsgegevens verwerken.
- Security one-pager — compacte samenvatting voor inkoop en management.
- Incident-koppeling — vastgelegde communicatiekanalen en escalatiepad voor 24u/72u/1m-meldingen.
Wat wij eerlijk niet kunnen leveren
Sales-praat hoort niet thuis in een security-document. Daarom expliciet wat wij niet leveren:
- Geen ISO 27001-certificering. Onze ISMS is wel ingericht volgens de norm, maar er is geen externe auditor die dat formeel heeft vastgesteld. Voor opdrachtgevers die certificering eisen kunnen wij doorverwijzen of meedenken over een gezamenlijk traject.
- Geen 24/7 SOC. Onze incident-detectie en -respons werkt op werkdagen tijdens kantooruren, met escalatie buiten die tijden via on-call. Voor klanten met strenge SLA-eisen werken we samen met gespecialiseerde MSSP's.
- Geen pentest-rapport tenzij afgesproken. Pentests kunnen we organiseren via partners; ze zijn geen standaard onderdeel van het Coding Agency-leveringsproces.
Volgende stap
Wil je een vendor security questionnaire ingevuld krijgen, een DPA opvragen of sparren over hoe wij jouw NIS2-traject kunnen ondersteunen? Neem contact op of stuur direct een e-mail naar contact@coding.agency. We reageren binnen één werkdag.
De volledige technische onderbouwing — hosting, encryptie, toegangsbeheer, incidentrespons en subverwerkers — staat op onze security & vertrouwen-pagina.
