Hoe MonkeySoft werkt volgens ISO 27001, NEN 7510 en ISO 42001

“Wij nemen beveiliging serieus” staat op bijna elke IT-dienstverlener zijn website. Zonder onderbouwing is dat een loze zin. Bij MonkeySoft hebben we die onderbouwing: een intern managementsysteem voor informatiebeveiliging (ISMS), ingericht volgens de principes van ISO/IEC 27001, aangevuld met NEN 7510 voor zorg-gerelateerde gegevens en ISO/IEC 42001 voor verantwoord gebruik van AI.

In dit artikel leggen we uit wat dat concreet betekent: welk beleid er ligt, hoeveel maatregelen er zijn geimplementeerd, en hoe dit doorwerkt in de development-, hosting- en beheerdiensten die we aan klanten leveren.

Wat betekent het dat MonkeySoft volgens ISO 27001 en NEN 7510 werkt?

Kort antwoord: MonkeySoft heeft een volledig ISMS ingericht conform ISO/IEC 27001, met alle 93 Annex A-controls geimplementeerd en gedocumenteerd. Het formele externe certificeringstraject loopt momenteel.

Een belangrijk onderscheid dat we bewust transparant maken: er is verschil tussen werken volgens een norm en gecertificeerd zijn voor die norm. Certificering is een momentopname: een externe auditor beoordeelt op een vast moment of het systeem aan de norm voldoet. Werken volgens de norm is de dagelijkse praktijk die aan die beoordeling voorafgaat, en die blijft doorlopen, ook na certificering.

Bij MonkeySoft is die dagelijkse praktijk al volledig ingericht: beleid, procedures, een risicoregister, een incidentregister en bewijs dat maatregelen daadwerkelijk worden uitgevoerd. Het formele certificeringstraject met een externe auditor is de volgende stap, geen voorwaarde om nu al zorgvuldig te werken.

Waarom dit onderscheid ertoe doet

Sommige partijen claimen “ISO 27001-proof” te zijn zonder dat er een auditeerbaar systeem achter zit. Wij kiezen voor de omgekeerde volgorde: eerst het systeem grondig inrichten en laten werken, dan pas de formele certificering aanvragen. Zo is elke uitspraak die we doen te herleiden tot een concreet document, een concrete control of een concreet bewijsstuk.

Hoe ons ISMS is opgebouwd: van beleid tot bewijs

Kort antwoord: ons ISMS bestaat uit een keten van beleid, controls, procedures en bewijs, allemaal onderling verwezen en centraal beheerd, niet als losse documenten.

De opbouw volgt een vaste keten:

• 17 beleidsdocumenten, van informatiebeveiliging en privacy tot AI, toegangsbeveiliging, classificatie, cryptografie, secure development en fysieke beveiliging
• 93 Annex A-controls, elk met een eigenaar, status en reviewdatum
• 24 procedures, die beschrijven hoe een control in de praktijk wordt uitgevoerd, van interne audits tot patchmanagement
• Bewijs, dat aantoont dat een procedure daadwerkelijk is gevolgd, niet alleen op papier bestaat
• Een risicoregister van 15 geidentificeerde risico’s, elk gekoppeld aan de controls die het risico mitigeren

Dit geheel wordt periodiek gevalideerd met geautomatiseerde controles: zijn alle documenten actueel, heeft elke control een eigenaar, resolven alle bewijsverwijzingen. Op het moment van schrijven zijn dat 8 van de 8 automatische checks geslaagd, over 64 documenten en 157 documenten en controls samen.

93 beveiligingsmaatregelen, geen losse claim: de Annex A-controls

Kort antwoord: alle 93 controls uit Annex A van ISO 27001 zijn bij MonkeySoft geimplementeerd, verdeeld over vier categorieen: organisatorisch, mensen, fysiek en technologisch.

Organisatorische maatregelen (A.5)

Het grootste deel van de controls is organisatorisch: beleid, rollen, verantwoordelijkheden en processen. Denk aan het informatiebeveiligingsbeleid dat als kaderbeleid boven alle andere beleidsdocumenten staat, het leveranciersbeveiligingsbeleid dat elke leverancier laat classificeren op basis van gegevenstoegang, en het incidentmanagementbeleid dat vastlegt hoe een beveiligingsincident wordt opgepakt.

Mensen (A.6)

Techniek alleen is niet genoeg. Bij indiensttreding, functiewijziging en uitdiensttreding volgt MonkeySoft een vaste joiner-mover-leaver-procedure, met toegang die binnen 1 werkdag na uitdiensttreding wordt ingetrokken. Daarnaast is er een doorlopend bewustwordings- en trainingsprogramma voor medewerkers.

Fysieke beveiliging (A.7)

Ook fysieke beveiliging is meegenomen: van toegang tot kantoorlocaties tot een clear-desk-beleid voor apparatuur en documenten.

Technologische maatregelen (A.8)

Het grootste technische blok omvat onder andere multi-factor authenticatie verplicht voor alle toegang tot productiesystemen, Azure, Microsoft 365 en GitHub, rol-gebaseerde autorisatie op basis van need-to-know, gescheiden ontwikkel-, test- en productieomgevingen, en een vaste secure development lifecycle met threat modelling, code review, geautomatiseerde securitytests in de CI/CD-pijplijn en periodieke penetratietests.

NEN 7510: extra waarborgen voor zorg- en gevoelige persoonsgegevens

Kort antwoord: NEN 7510 volgt dezelfde Annex A-structuur als ISO 27001, met extra eisen voor gezondheidsgegevens, en is bij MonkeySoft specifiek van toepassing op de onderdelen die met gezondheids- of vergelijkbaar gevoelige persoonsgegevens werken.

Voor organisaties die met patientgegevens of andere bijzondere persoonsgegevens werken, is NEN 7510 relevanter dan de generieke ISO 27001-norm. De norm stelt strengere eisen aan onder meer toegangscontrole, logging en het aantoonbaar borgen van vertrouwelijkheid. Voor zorginstellingen die met MonkeySoft samenwerken, betekent dit dat dezelfde grondige aanpak wordt toegepast als bij onze eigen zorg-gerelateerde productonderdelen.

ISO 42001: verantwoord gebruik van AI

Kort antwoord: MonkeySoft past de principes van ISO/IEC 42001 toe op zowel AI-ondersteunde ontwikkeling als AI-functionaliteit in producten, met een vast goedkeuringsproces, risicobeoordeling en menselijk toezicht.

AI-tools zoals GitHub Copilot en Claude Code worden bij de ontwikkeling van software ingezet, maar niet zonder kader. Voordat een AI-systeem in gebruik gaat, doorloopt het een goedkeuringsproces. Elk AI-systeem wordt geregistreerd in een AI-inventory en krijgt een risicobeoordeling volgens een vaste methodologie. Daarnaast geldt een human oversight framework: AI-output wordt niet blindelings overgenomen, er is altijd een mens die de uiteindelijke beslissing neemt of controleert.

Concreet omvat dit AI-governance-kader:

• Een goedkeuringsproces voorafgaand aan ingebruikname van een AI-systeem
• Een AI-risicoregister, naast het algemene risicoregister
• Een ethisch kader voor AI-gebruik
• Beoordeling van AI-leveranciers, zoals modelproviders
• Een specifieke procedure voor AI-gerelateerde incidenten
• Doorlopende monitoring van AI-systemen in productie

Dit geldt zowel voor AI die wordt gebruikt tijdens het bouwen van software, als voor AI-functionaliteit die in producten zelf terechtkomt.

Risicomanagement, incidentmanagement en bedrijfscontinuiteit

Kort antwoord: risico’s, incidenten en bedrijfscontinuiteit worden bij MonkeySoft niet ad hoc behandeld, maar volgens vaste, herhaalbare procedures met een register en een testcyclus.

• Risicomanagement: 15 geidentificeerde risico’s, elk met een vaste beoordelingsmethodologie en koppeling aan de controls die het risico mitigeren
• Incidentmanagement: een vaste incidentresponsprocedure, met incidenten die worden gelogd, opgevolgd en geanalyseerd op herhaling
• Bedrijfscontinuiteit: een continuiteitsplan met RTO en RPO per systeem, regelmatig getest via een vaste BCM/DR-testprocedure
• Disaster recovery: een technisch uitgewerkt herstelplan voor grote verstoringen, los getest van de dagelijkse back-upprocedure

Deze aanpak sluit direct aan op de bredere zorgplicht die ook naar voren komt in onze uitleg over de Cyberbeveiligingswet, en op de manier waarop we backup en continuiteit voor klanten inrichten.

Wat dit betekent voor development, hosting en beheer bij MonkeySoft

Kort antwoord: de policies, procedures en technische standaarden die ons ISMS vormen, zijn niet losgekoppeld van klantwerk, maar de dagelijkse werkwijze van dezelfde mensen die development, hosting en beheer leveren.

Het ISMS is formeel opgezet rond de eigen MonkeySoft-producten en de gedeelde platforminfrastructuur: Azure, Microsoft 365, GitHub en de CI/CD-pijplijnen daaronder. Maar de onderliggende maatregelen zijn niet productspecifiek, het zijn de standaarden die het hele engineeringteam volgt:

• Development: secure development lifecycle met threat modelling, verplichte code review, geautomatiseerde securitytests en periodieke penetratietests, ook toegepast op maatwerk software voor klanten
• Hosting: versleuteling, netwerksegmentatie, logging en monitoring volgens vaste technische standaarden, ook bij Europese cloud-hosting
• Beheer: toegangsbeheer op basis van need-to-know, MFA-verplichting en periodieke toegangsreviews, ook voor klantomgevingen binnen Microsoft Cloud-beheer
• Integraties: leveranciersbeoordeling en dataresidentie-checks vóór een nieuwe koppeling live gaat, relevant voor onze integratiedienstverlening

Met andere woorden: een klant die development, hosting of beheer bij MonkeySoft afneemt, profiteert van dezelfde discipline die aan de basis ligt van ons eigen ISMS, ook al valt het specifieke klantproject niet altijd binnen de formele certificeringsscope.

Waarom transparantie belangrijker is dan een logo op de website

Kort antwoord: een certificeringslogo zegt weinig als de onderliggende praktijk niet auditeerbaar is; wij kiezen ervoor om te laten zien wat er daadwerkelijk staat, ook voordat de formele certificering is afgerond.

We begrijpen dat “in opbouw” minder indrukwekkend klinkt dan een certificeringslogo. Maar een logo zonder onderliggend, werkend systeem is minder waard dan een grondig ingericht systeem zonder logo. Daarom delen we liever concrete cijfers: 93 van de 93 Annex A-controls geimplementeerd, 17 beleidsdocumenten, 24 procedures, een werkend risico- en incidentregister, dan een claim die niet te verifieren is.

Zodra het externe certificeringstraject is afgerond, communiceren we dat uiteraard. Tot die tijd is de eerlijke stand van zaken: het systeem werkt, staat, en wordt dagelijks toegepast.

Veelgestelde vragen (FAQ)

Is MonkeySoft ISO 27001 gecertificeerd?

MonkeySoft heeft een volledig ISMS ingericht conform ISO/IEC 27001, met alle 93 Annex A-controls geimplementeerd en voorzien van bewijs. Het formele certificeringstraject met een externe auditor loopt momenteel.

Wat is het verschil tussen ISO 27001 en NEN 7510?

ISO 27001 is de internationale norm voor informatiebeveiligingsmanagement voor de hele organisatie. NEN 7510 is de Nederlandse norm specifiek voor de zorgsector, met extra eisen voor gezondheidsgegevens.

Wat houdt ISO 42001 voor AI in?

ISO/IEC 42001 is de norm voor een AI-managementsysteem: hoe een organisatie AI verantwoord ontwikkelt, inzet en bewaakt, inclusief goedkeuringsproces, risicobeoordeling en menselijk toezicht.

Geldt dit beleid ook voor maatwerkprojecten van klanten?

De formele ISMS-scope betreft de eigen producten en gedeelde platforminfrastructuur. Dezelfde onderliggende procedures en technische standaarden worden echter ook toegepast bij development, hosting en beheer voor klanten.

Wat is een Annex A-control?

Annex A van ISO 27001 is een lijst van 93 concrete beveiligingsmaatregelen, verdeeld over organisatorisch, mensen, fysiek en technologisch. Elke maatregel heeft bij MonkeySoft een eigenaar, status en bewijs.

Conclusie

MonkeySoft werkt volgens de principes van ISO 27001, aangevuld met NEN 7510 voor zorg-gerelateerde gegevens en ISO 42001 voor verantwoord AI-gebruik. Dat is geen marketingclaim, het is terug te voeren op 17 beleidsdocumenten, 93 geimplementeerde Annex A-controls, 24 procedures en een werkend risico- en incidentregister.

Het formele externe certificeringstraject loopt, en we communiceren daar transparant over: de praktijk staat, de formele bevestiging volgt. Voor klanten betekent dit dat development, hosting en beheer bij MonkeySoft zijn ingebed in dezelfde discipline die ons eigen ISMS draagt.

Meer weten over hoe dit voor jouw project of organisatie uitpakt? Neem contact op met MonkeySoft.

Bronnen: ISO.org, ISO/IEC 27001 | NEN, NEN 7510:2024