De documentatie van het ISMS is van bovengemiddelde kwaliteit: vrijwel alle 93 controls zijn concreet en YipYip-specifiek beschreven, de NEN7510-Z maatregelen zijn realistisch herschreven vanuit de verwerker-rol, en de Git-based opzet met CI-validatie is een sterk fundament. De partial controls beschrijven hun gaps eerlijk — dat is precies hoe het hoort.
De werking van het ISMS is echter niet aantoonbaar. De vier kernprocessen van de PDCA-cyclus zijn geen van alle uitgevoerd: er is geen risicobeoordeling gedaan (het register is een ongevuld template), het IB-beleid en de VvT zijn niet ondertekend, er is geen interne audit geweest (auditor niet aangesteld) en geen directiebeoordeling. De eigen jaarplanning (risicobeoordeling afgerond in Q2, interne audits Q1/Q2) is per auditdatum (12 juni 2026) al overschreden. Daarnaast zijn drie van de zes registers in Git ongevulde of fictieve templates die de werkelijkheid tegenspreken, en claimen meerdere implemented controls bewijs dat niet bestaat (certificaten, auditrapporten, beoordelingsrecords).
Het patroon: het beschrijvende werk is af, het aantoonbare werk moet nog beginnen. Een externe auditor toetst op werking, niet op tekst.
| Categorie |
Aantal |
| Major Non-Conformiteiten (NCM) |
5 |
| Minor Non-Conformiteiten (NCn) |
16 |
| Observaties (OBS) |
7 |
| Positieve Bevindingen (POS) |
7 |
Niet gereed voor een externe certificeringsaudit. Elke certificerende instelling wijst af op het ontbreken van een uitgevoerde risicobeoordeling, een directiebeoordeling en een interne audit — dit zijn harde clausule-eisen (6.1, 9.2, 9.3). Minimaal vereist vóór een externe audit: NCM-001 t/m NCM-004 opgelost, plus aantoonbaar geteste kernprocessen (incident response, backup-restore). De documentatiebasis is goed genoeg om dit binnen één à twee kwartalen te realiseren.
| Veld |
Waarde |
| Clausule/Control |
ISO 27001:2022 clausules 6.1.2, 6.1.3, 8.2, 8.3 |
| Norm-eis |
De organisatie moet informatiebeveiligingsrisicobeoordelingen uitvoeren met geplande tussenpozen en de resultaten als gedocumenteerde informatie bewaren; het behandelplan moet zijn vastgesteld en restrisico’s goedgekeurd door risico-eigenaren. |
| Bevinding |
06-planning/6.1-risicobeoordeling/6.1.3-behandelplan.md stelt: “Er zijn nog geen formele behandelplannen — de eerste volledige risicobeoordeling wordt gepland in 2026.” 08-uitvoering/8.2 en 8.3 bevestigen dit (“gepland Q1-Q2 2026” — verstreken). Het risicoregister (risico-register.yaml) heeft status template, bevat twee voorbeeldrisico’s en [IN TE VULLEN] als risico-eigenaar. De frontmatter van 6.1.1 en 6.1.3 zegt desondanks implemented. |
| Bewijs |
6.1.1-algemeen.md, 6.1.3-behandelplan.md, risico-register.yaml, 8.2-risicobeoordeling.md, 8.3-risicobehandeling.md |
| Impact |
De risicobeoordeling is het fundament van het hele ISMS: zonder uitgevoerde beoordeling is de SoA-selectie niet onderbouwd en faalt clausule 6 én 8. Directe afwijzingsgrond bij certificering. |
| Aanbevolen actie |
Eerste volledige risicobeoordeling uitvoeren conform de eigen methodiek (die is gereed), resultaten vastleggen in Sheets + YAML-export, behandelplan opstellen, restrisico’s door directie laten accepteren. Status van 6.1.1/6.1.3 corrigeren totdat dit is gebeurd. |
| Veld |
Waarde |
| Clausule/Control |
ISO 27001:2022 clausule 5.2 / A.5.1 |
| Norm-eis |
De directie moet een informatiebeveiligingsbeleid vaststellen dat gecommuniceerd wordt binnen de organisatie en beschikbaar is voor belanghebbenden. |
| Bevinding |
05-leiderschap/5.2-beleid.md bevat als datum “[te ondertekenen wanneer ISMS gereed is]”. In controls/_index.yaml zijn vastgesteld-door en datum-vaststelling van de VvT null. Er is geen bewijs van communicatie aan medewerkers. Verzwarend: 5.1-commitment.md voert “Ondertekend IB-beleid” op als bewijs van directiebetrokkenheid — dat bewijs bestaat niet. |
| Bewijs |
5.2-beleid.md, 5.1-commitment.md, controls/_index.yaml (metadata) |
| Impact |
Clausule 5.2 is een minimumvereiste; een niet-vastgesteld beleid betekent dat formeel niets van het ISMS gedragen wordt door de directie. |
| Aanbevolen actie |
Beleid en VvT ondertekenen (kost een ochtend), communiceren via teamoverleg + mail, kennisname vastleggen. Bewijsclaim in 5.1 corrigeren tot ondertekening een feit is. |
| Veld |
Waarde |
| Clausule/Control |
ISO 27001:2022 clausule 9.3 |
| Norm-eis |
De directie moet het ISMS met geplande tussenpozen beoordelen; resultaten moeten als gedocumenteerde informatie worden bewaard. |
| Bevinding |
9.3-directiebeoordeling.md: “Nog geen directiebeoordeling uitgevoerd… De eerste volledige directiebeoordeling vindt plaats in december 2026.” De eigen procedure schrijft bovendien een halfjaarlijkse tussentijdse update voor in juni — daarvan is per auditdatum (12 juni) geen bewijs. |
| Bewijs |
09-evaluatie/9.3-directiebeoordeling.md |
| Impact |
Zonder minimaal één uitgevoerde directiebeoordeling met notulen is certificering niet mogelijk; ook intern ontbreekt daarmee de Check/Act-cyclus op directieniveau. |
| Aanbevolen actie |
Directiebeoordeling niet uitstellen tot december: plan er één direct na afronding van de risicobeoordeling en de eerste interne audit (bijv. Q3), met notulen conform het eigen format. |
| Veld |
Waarde |
| Clausule/Control |
ISO 27001:2022 clausule 9.2 |
| Norm-eis |
De organisatie moet interne audits uitvoeren met geplande tussenpozen; een auditprogramma moet zijn geïmplementeerd. |
| Bevinding |
9.2.1-programma.md: “De eerste interne audit is gepland voor 2026. De auditor is nog niet aangesteld.” De eigen jaarplanning (Q1: clausules 4–6, Q2: clausules 7–8) is per auditdatum niet uitgevoerd; de map 09-evaluatie/9.2-interne-audit/audits/ is leeg. Dit Claude Code-rapport is een hulpmiddel en vervangt de vereiste onafhankelijke interne audit niet. |
| Bewijs |
9.2.1-programma.md, lege audits/ directory |
| Impact |
Clausule 9.2 vereist een werkend auditprogramma vóór certificering; certificeerders willen minimaal één volledige auditcyclus zien. |
| Aanbevolen actie |
Externe interne auditor contracteren (zoals het programma zelf voorschrijft) en de eerste audit in Q3 uitvoeren. |
| Veld |
Waarde |
| Clausule/Control |
ISO 27001:2022 clausule 7.5 / A.5.9, A.5.19–5.22, A.8.32 |
| Norm-eis |
Gedocumenteerde informatie moet actueel, juist en beheerst zijn; er moet een inventaris van informatie en assets bestaan. |
| Bevinding |
registers/assets.yaml bevat placeholders ([DATACENTER], [LEVERANCIER], [ADRES]), niet-gedefinieerde rollen (“IT Manager”, “IT Beheer”, “Facilities”, “Sales/Account Management”) en feitelijk onjuiste inhoud (“Azure/AWS”, “Productie Servers” — YipYip gebruikt AWS/GCP en heeft geen eigen servers). registers/leveranciers.yaml bevat alleen placeholder-leveranciers. registers/wijzigingen.yaml beschrijft een fictieve wekelijkse CAB met “IT Manager” en “Operations”. Tegelijk voeren controls 5.09, 5.19, 5.20, 5.22 en 8.32 (allemaal implemented of zonder gemelde gap) deze registers op als bewijs. |
| Bewijs |
registers/assets.yaml, registers/leveranciers.yaml, registers/wijzigingen.yaml, genoemde controls |
| Impact |
Een auditor die één register opent ziet direct dat het bewijs niet klopt — dat ondermijnt de geloofwaardigheid van álle bewijsclaims. Misleidend bewijs is erger dan ontbrekend bewijs. |
| Aanbevolen actie |
Per register kiezen: vullen met werkelijke gegevens, óf vervangen door een expliciete verwijzing naar de operationele bron (Google Sheet) met sync-afspraak. Fictieve inhoud (CAB, Azure, servers) verwijderen. |
Compact weergegeven; elke regel is een zelfstandige bevinding met dezelfde bewijslast als hierboven.
| # |
Bevinding |
Locatie |
Aanbevolen actie |
| NCn-001 |
Status implemented met onbestaand bewijs: 5.35 voert “Certificaten ISO 27001/NEN7510” en certificeringsauditrapporten op (certificering is nog niet behaald); 5.36 voert interne auditrapporten en management-reviewverslagen op (bestaan niet). |
5.35-independent-review.md, 5.36-compliance.md |
Status naar partial of bewijs herformuleren naar wat er wél is. |
| NCn-002 |
5.22 (implemented, “Geen bekende gaps”) claimt “beoordelingsrecords in leveranciersregister” — het register is leeg. |
5.22-supplier-monitoring.md |
Beoordelingsrecords aantoonbaar maken of status corrigeren. |
| NCn-003 |
5.15 is implemented terwijl de eigen gaps-sectie meldt dat de autorisatiematrix (04.02a) “nog te migreren” is en uniform MFA-beleid ontbreekt. |
5.15-access-control.md |
Matrix migreren; tot die tijd status partial. |
| NCn-004 |
Incidentproces (5.24–5.26) is nooit getest, ook niet via tabletop; 5.25/5.26 staan desondanks op implemented. |
5.24–5.26 |
Tabletop exercise uitvoeren en vastleggen. |
| NCn-005 |
Logs worden gegenereerd (8.15 implemented) maar nergens gereviewd; geen detectie van verdacht gedrag (8.16). Bij een inbraak is ontdekking toeval. |
8.15-logging.md, 8.16-monitoring.md, 5.23 |
Periodieke log review instellen (maandelijks is voor deze omvang voldoende); alerting op kritieke events. |
| NCn-006 |
Geen penetratietest of structurele security testing, terwijl doelstelling 5 (6.2-doelstellingen.md) een jaarlijkse pentest belooft en de pentest-leverancier “nog te contracteren” is. |
8.08, 8.29, 6.2-doelstellingen.md |
Pentest contracteren (zie ook issue #58). |
| NCn-007 |
Continuïteits- en herstelprocessen nooit getest: geen restore-test, failover-test of tabletop (5.29, 5.30, 8.13). Strijdig: Z8 claimt een “kwartaallijkse hersteltest per project”. |
5.29, 5.30, 8.13, z08-care-continuity.md |
Restore-test uitvoeren; claim in Z8 corrigeren of waarmaken. |
| NCn-008 |
8.32 is implemented met materiële eigen gaps (handmatige OS/infra-patching, alfa/beta-overgang ongedefinieerd) en verwijst als bewijs naar het fictieve wijzigingsregister. |
8.32-change-management.md |
Status heroverwegen; bewijsverwijzing corrigeren. |
| NCn-009 |
Medewerkersaantal inconsistent: ~10 (4.1), ~15 (scope.md, Z4), ~17 (5.1, 5.3, rollen.yaml). |
4.1-organisatie.md, 00-meta/scope.md, e.a. |
Eén getal kiezen en overal doorvoeren. |
| NCn-010 |
Verouderde normreferentie: 4.2 noemt als certificeringseis “NEN 7510:2017+A1:2020” terwijl het ISMS NEN7510:2024 hanteert. |
4.2-belanghebbenden.md |
Corrigeren naar NEN7510:2024. |
| NCn-011 |
nen7510/mapping.yaml heeft status draft en gebruikt de oude 2017-structuurnummering (5.1.1, 6.1.1, 7.1.1) i.p.v. de NEN7510:2024-structuur. |
nen7510/mapping.yaml |
Mapping actualiseren naar 2024-structuur en vaststellen. |
| NCn-012 |
Niet-gedefinieerde rollen in actieve documenten: “security officer” (5.24 meldproces), “isms-manager” (escalatie in incidenten.yaml), “IT Manager”/“Operations”/“CAB” (registers). |
5.24-incident-planning.md, registers/incidenten.yaml, registers |
Vervangen door rollen uit rollen.yaml. |
| NCn-013 |
Tegenstrijdigheid identity provider: 5.16 zegt “Geen centrale IdP”, 8.05 zegt “Google Workspace fungeert als centrale identiteitsprovider”. |
5.16, 8.05 |
Eén formulering kiezen die de werkelijkheid dekt (Workspace = SSO voor déél van de diensten). |
| NCn-014 |
Bewijsdocumenten uit het oude ISMS niet gemigreerd maar wel als bewijs opgevoerd: autorisatiematrix (04.02a, in 5.15), leveranciersbeoordelingsformulier (08.01a, in 5.19). Gap-tekst in 5.13 verwijst naar checklist 09.04a als “nog te migreren” terwijl die al volledig in Z4 staat (stale). |
5.15, 5.19, 5.13 |
Documenten migreren; stale gap-tekst in 5.13 schrappen. |
| NCn-015 |
Het enige awareness-sessierapport (awareness-sessions/26-03-25/report.md) is een leeg template (“Datum: JJJJ-MM-DD”, “Presentator: Naam”) — terwijl 6.03 rapportages als bewijs opvoert. Ook tools/sheets/awareness.md bevat nog [IN TE VULLEN]. |
awareness-sessions/26-03-25/report.md |
Rapport invullen; awareness-registratie operationeel maken. |
| NCn-016 |
5.19 heeft status partial maar gaps-sectie zegt “Geen bekende gaps” (innerlijk tegenstrijdig; gap-analyse #15 noemt wél een gap). Daarnaast: foutieve wetsnaam in scope.md (“Wbsn-z — Wet bescherming staatsgeheimen zorg”; bedoeld is de Wet gebruik BSN in de zorg, opgegaan in de Wabvpz) en kapotte link in 4.2 naar 5.29-continuity-readiness.md (bestand heet 5.29-disruption.md). |
5.19, 00-meta/scope.md, 4.2-belanghebbenden.md |
Gaps-sectie vullen, wetsnaam en link corrigeren. |
| # |
Observatie |
Aanbeveling |
| OBS-001 |
Functiescheiding: Tim Pelgrim is Directie, IB-coördinator én DevOps Lead — beleid, uitvoering en controle in één persoon. De externe interne auditor is een goede mitigatie, maar dit geconcentreerde risico is nergens expliciet als geaccepteerd restrisico vastgelegd. |
Expliciet vastleggen in de risicobeoordeling (past bij NCM-001) met compenserende maatregelen (vier-ogen via Tim Nooteboom, externe audit). |
| OBS-002 |
6.3-wijzigingen.md staat voor kleine wijzigingen “branch of direct op main” toe — strijdig met de eigen verplichte PR-workflow (CLAUDE.md, branch protection). |
Tekst aanpassen: alles via PR. |
| OBS-003 |
KPI-programma in 9.1 is ambitieus (maandelijkse dashboards, wekelijkse backup-KPI’s) maar er is geen bewijs dat het draait. Risico op papieren werkelijkheid. |
KPI-set verkleinen tot wat aantoonbaar wordt gemeten; uitbreiden kan later. |
| OBS-004 |
evidence/ is leeg terwijl meerdere controls en Z-docs ernaar verwijzen (bekend: issue #33). Gap-analyse heeft datum januari 2026 en bevat stale items (bekend: issue #37). |
Bestaande issues #33 en #37 oppakken vóór de externe audit. |
| OBS-005 |
Het validatiescript controleert frontmatter en SoA-sync, maar niet: kapotte interne links, [IN TE VULLEN]-markers, of rolnamen binnen registers/YAML. Drie van de bevindingen hierboven waren dan automatisch gevangen. |
Script uitbreiden met deze checks. |
| OBS-006 |
Formulering in 8.3 stap 6: “directie keurt af (hoog/kritiek)” — bedoeld is “keurt goed”. |
Corrigeren. |
| OBS-007 |
CLAUDE.md (“Huidige status” / “Bekende problemen”) loopt achter op de werkelijkheid (noemt o.a. Jira-placeholders en NEN7510-placeholders die al zijn opgelost). |
Bijwerken na deze audit. |
| # |
Bevinding |
Waarom positief |
| POS-001 |
Partial controls beschrijven hun gaps eerlijk en concreet (5.24, 8.13, 8.16, 8.24, 5.37). |
Aantoonbare zelfkennis; precies wat een auditor wil zien. Niet “wegpoetsen” richting certificering. |
| POS-002 |
People-controls (6.01, 6.05, 6.06) zijn concreet en verifieerbaar: VOG’s, getekende checklists, geheimhouding in arbeidscontract, alles in het personeelsdossier. |
Klein aantal maatregelen, maar volledig en aantoonbaar — het sterkste hoofdstuk. |
| POS-003 |
NEN7510-Z maatregelen zijn herschreven vanuit YipYip’s werkelijke rol als verwerker/softwareleverancier, met heldere verantwoordelijkheidsverdeling YipYip↔klant. |
Veel ICT-dienstverleners kopiëren zorginstellings-teksten; dit is doordacht en verdedigbaar bij een auditor. |
| POS-004 |
Verwerkingsregister (verwerkingsactiviteiten.yaml) is volledig gevuld, inclusief grondslagen, bewaartermijnen en doorgifte buiten EER. |
Het enige register dat als voorbeeld kan dienen voor de andere. |
| POS-005 |
Git-based ISMS met CI-validatie, rollenregister als bron van waarheid en changelog-discipline. |
Versiebeheer en consistentie-checks zijn structureel geborgd — beter dan de meeste document-gebaseerde ISMS’en. |
| POS-006 |
SDLC (8.25) is sterk: branch protection, verplichte review, gescheiden omgevingen, nooit echte data in test, testbeleid per endpoint. |
Kernproces van het bedrijf is ook het best beveiligde proces. |
| POS-007 |
De 10-punts checklist zorgapplicaties (Z4) is volledig gemigreerd en verankerd in het ontwikkelproces (kick-off → review → Definition of Done). |
Zorgspecifieke borging zit in het dagelijkse werk, niet in een la. |
Alle documenten in 04-context/, 05-leiderschap/, 06-planning/, 07-ondersteuning/, 08-uitvoering/, 09-evaluatie/, 10-verbetering/ (.md, volledige inhoud).
- Alle 19 partial controls: 5.01, 5.05, 5.12, 5.13, 5.19, 5.24, 5.29, 5.30, 5.32, 5.37, 7.04, 8.07, 8.08, 8.09, 8.13, 8.16, 8.24, 8.27, 8.29
- Steekproef implemented (26 van 74 = 35%, risicogestuurd): 5.02, 5.09, 5.15, 5.16, 5.17, 5.20, 5.22, 5.23, 5.25, 5.26, 5.31, 5.34, 5.35, 5.36, 6.01, 6.03, 6.05, 6.08, 7.02, 8.01, 8.02, 8.05, 8.15, 8.25, 8.31, 8.32
controls/_index.yaml (SoA, volledig)
registers/assets.yaml, incidenten.yaml, leveranciers.yaml, rollen.yaml, verwerkingsactiviteiten.yaml, wijzigingen.yaml06-planning/6.1-risicobeoordeling/risico-register.yaml
nen7510/mapping.yamlnen7510/zorg-specifiek/z01–z08 (alle)
00-meta/scope.md, 00-meta/gap-analyse.md, 00-meta/changelog.mdawareness-sessions/26-03-25/report.mdscripts/validate-isms.mjs (uitgevoerd: alle checks geslaagd)- GitHub issues (open/gesloten, duplicaatcheck)
- Documentatiekwaliteit en eerlijkheid van de gap-beschrijvingen
- Technische ontwikkelpraktijk (SDLC, omgevingsscheiding, toegang tot productie)
- NEN7510-invulling vanuit de werkelijke verwerker-rol
- Geautomatiseerde consistentie-bewaking (CI-validatie)
- Risicobeoordeling uitvoeren (NCM-001) — fundament voor al het overige, methodiek ligt klaar
- IB-beleid + VvT ondertekenen en communiceren (NCM-002) — kost een ochtend
- Interne auditor aanstellen en eerste audit draaien (NCM-004)
- Directiebeoordeling uitvoeren (NCM-003) — na 1 en 3, niet wachten tot december
- Registers waarheidsgetrouw maken (NCM-005) en status-mismatches corrigeren (NCn-001 t/m 003, 008)
- Kernprocessen testen: tabletop incident response + restore-test (NCn-004, 007)
Stop met documenteren — de tekst is af. Alle resterende inspanning moet naar uitvoeren en vastleggen: risicobeoordeling, ondertekening, audit, directiebeoordeling, tests. Realistisch tijdpad: NCM’s opgelost in Q3, externe audit aanvragen voor Q4 2026 / Q1 2027. De documentatiebasis is goed genoeg om dat tempo te halen, mits er capaciteit wordt vrijgemaakt naast het projectwerk (zie OBS-001: vrijwel alles leunt op één persoon).
Gegenereerd door Claude Code audit skill op 2026-06-12. Dit rapport is een hulpmiddel voor interne kwaliteitsverbetering en vervangt geen formele certificeringsaudit door een geaccrediteerde instelling.
