ISO 27001 risicoanalyse is het proces waarmee je informatiebeveiligingsrisico’s identificeert, beoordeelt en behandelt op een manier die auditors kunnen volgen — zonder dat ISO voorschrijft welke methodiek je exact moet gebruiken. Het risicoregister is het kompas voor je SoA, je budget en je interne prioriteiten.
Een goede risicoanalyse verbindt bedrijfsrealiteit met Annex A: niet elke control is relevant, maar elke relevante control moet terug te leiden zijn naar een risico of expliciete uitsluiting. Voor SaaS en MKB betekent dit vaak: focus op identity, keten, ontwikkelproces en dataresidency — niet op generieke checklists zonder eigenaar.
Wat betekent dit?
Risicoanalyse in ISO 27001 omvat identificatie van bedreigingen en kwetsbaarheden, inschatting van impact en waarschijnlijkheid, en keuze van behandeling: mitigeren, accepteren, overdragen of vermijden. De norm vraagt dat je criteria vastlegt vóór je gaat scoren — anders is achteraf bijstellen moeilijk te verdedigen.
Het risicoregister is levend document: assets, bedreigingen, huidige controls, rest-risico, eigenaar en reviewdatum. Auditors steekproeven op hoog-risico items en volgen de keten naar tickets, configuraties en managementbesluiten over acceptatie.
Methodiek mag lichtgewicht zijn — qualitative matrices werken voor veel MKB — mits consistent toegepast en periodiek herzien. Enterprise teams gebruiken soms FAIR of CRQ; dat is geen vereiste, wel een keuze die je moet kunnen uitleggen aan stage 1 auditors.
Risicobehandeling koppelt direct aan SoA: elke gekozen maatregel hoort een risico-ID te hebben. Omgekeerd: risico’s zonder behandeling of acceptatiebesluit zijn rode vlaggen — vooral als er klantdata of NIS2-relevante diensten spelen.
Threat modeling in development kan onderdeel zijn van risico-identificatie voor productteams — het ISMS hoeft geen apart universum te zijn naast engineering, maar moet wel dezelfde taal spreken over impact en eigenaarschap.
Voor wie is dit relevant?
CISO’s en security officers gebruiken het register voor roadmap en rapportage aan MT. Product owners hebben risico’s nodig om security-eisen in releases te prioriteren — zonder register blijft het discussie in Slack.
Compliance officers koppelen risico’s aan contractuele beloften en DPIA’s. Finance wil zicht op acceptatiebesluiten met budgetimpact — bijvoorbeeld wanneer rest-risico wordt geaccepteerd omdat mitigatie duurder is dan verwachte schade.
MKB met beperkte capaciteit wint door top-10 risico’s scherp te houden en quarterly review te plannen — niet door honderden rijen te vullen die niemand bijwerkt. Scale-ups in hypergrowth moeten risico’s herzien bij elke nieuwe regio, integratie of pricing tier met extra data.
Interne auditors gebruiken het register als steekproefkader — zij kiezen risico’s met hoge impact of recente wijzigingen en volgen bewijs of behandeling werkelijk is uitgevoerd.
Welke eisen of stappen horen erbij?
Definieer risicocriteria met MT: schaal voor impact (financieel, reputatie, wettelijk) en waarschijnlijkheid, plus drempel voor acceptatie. Leg vast wie risicoacceptatie mag goedkeuren — vaak MT of gedelegeerd mandaat met drempelbedragen.
Inventariseer assets en datastromen — koppel aan scope uit clausule 4. Identificeer bedreigingen per asset: unauthorized access, ransomware, leveranciersuitval, insider threat, misconfiguratie in cloud.
Score, prioriteer en kies behandeling. Documenteer rest-risico en eigenaar per item. Koppel behandeling aan concrete acties met deadline — geen ‘implementeer MFA’ zonder ticket.
Herzie minimaal jaarlijks en bij significante wijzigingen: nieuwe productlijn, acquisitie, grote leverancierswissel. Koppel updates aan management review en interne auditplanning.
Veelgemaakte fouten
Register kopiëren van template zonder organisatie-specifieke assets — auditors merken generieke bedreigingen zonder koppeling aan jullie stack. Tweede fout: scores zonder criteria — iedereen kiest ‘medium’ om discussie te vermijden.
Derde fout: risico’s wel benoemen maar niet behandelen — SoA vult controls in terwijl register leeg blijft qua acties. Vierde fout: geen koppeling met incidenten en near-misses; lessons learned komen niet terug in scores.
Vijfde fout: privacy-risico’s apart houden zonder koppeling — AVG-artikel 32 en Annex A overlappen; dubbele registers leiden tot tegenstrijdige prioriteiten. Zesde fout: acceptatie zonder MT-besluit vastgelegd.
SaaS-specifiek: deployment-risico’s buiten register houden omdat ‘DevOps het wel regelt’ — auditors vragen naar change control en rollback na productie-incidenten.
Praktisch stappenplan
Start met workshop scope + assets; week 2: dreigingen en criteria; week 3: scoring en top-15; week 4: behandelplannen en SoA-koppeling; week 5: MT-review. Gebruik ISO 27001 scope en context als input.
Werk met één register in GRC-tool of strak spreadsheet met versiebeheer — geen parallelle Excel per afdeling. Koppel tickets in Jira/Linear aan risico-ID’s voor traceerbaarheid.
Plan steekproef voor interne audit: kies drie hoog-risico items en verzamel bewijs van mitigatie binnen 48 uur. Faalt dat, verbeter procedures vóór certificering. Zie Statement of Applicability voor vertaling naar controls.
Na certificering: koppel risico-review aan surveillance-rhythm — nieuwe CVE’s, leveranciersincidenten en pentest-bevindingen moeten binnen vaste termijn in het register landen.
Relatie met ISO 27001, NIS2, AVG of ISMS
Risicoanalyse is clausule 6.1 — brug tussen ISMS planning en certificering. NIS2 benadrukt ketenrisico’s — neem leveranciers en SaaS expliciet op als assets met eigen scores.
AVG en ISO 27001: DPIA-resultaten voeden risico’s over verwerking; meldplicht bij datalekken hoort in incidentproces gekoppeld aan register. Bewijslast toont dat behandeling werkt.
Leveranciersbeheer levert input voor ketenbedreigingen. Certificering kosten hangen mede af van scope en risicoprofiel — complexiteit drijft auditdagen.
Eén register met tags voor NIS2/AVG-specifieke items voorkomt dubbel werk en inconsistente prioriteiten richting auditors en klanten.
Quantitatieve scoring is zelden nodig voor MKB — wel moet je uitleggen waarom ‘hoog’ hoog is: impact op klantdata, uptime-SLA of wettelijke meldplicht. Documenteer dat gesprek in het register, niet alleen in workshop-notities.
Ketenrisico’s verdienen eigen rijen: identity-provider, e-mail, DNS, backup-SaaS en payment gateway — uitval of compromise daar raakt meerdere Annex A-controles tegelijk.
Herbeoordeling na pentest: elke medium+ bevinding krijgt risico-ID of expliciete acceptatie met einddatum. Auditors koppelen pentest aan clausule 8.8 en 6.1 — losse PDF zonder registerupdate is zonde.
Risicotaal moet voor MT begrijpelijk zijn — vermijd pure CVSS-jargon in boardslides; vertaal naar klantimpact en contractuele boetes.
Scenario-oefeningen (ransomware, insider, cloud misconfig) voeden het register met realistische triggers — theoretische LOPA zonder scenario’s voelt hol in stage 2 interviews.
Kritieke afhankelijkheden van één engineer of één SaaS-leverancier verdienen expliciete risicorijen met bus-factor en exitplan — veel MKB-organisaties onderschatten concentratierisico tot de eerste keten-incident.
Risicoreview na elke significante klant-Audit of enterprise questionnaire: nieuwe eisen worden behandeling of acceptatie, niet ad-hoc spreadsheet naast het register.
Risicoworkshop output: top-15 met eigenaar, deadline behandeling en koppeling SoA-regel — MT accordeert in dezelfde vergadering; notulen zijn bewijs voor clausule 6 en management review.
Acceptatiebesluit template: rest-risico, business rationale, einddatum herziening, goedkeurder — auditors steekproeven op acceptatie zonder vervaldatum vinden stille permanentie.
Risico-eigenaar deputy invullen — bus-factor in risicoregister is volwassenheid, geen nice-to-have.
Koppel pentest bevindingen binnen 10 werkdagen aan risico-ID of acceptatie — losse PDF zonder registerupdate faalt surveillance.
Leg in het register ook afhankelijkheden van AI-features vast — prompt injection, model hosting en training data zijn nieuwe assets die auditors steeds vaker in stage 2 bespreken bij SaaS-leveranciers.
Documenteer risicoreview-cadans in het ISMS-handboek: kwartaal voor top-10, jaarlijks voor volledige register — auditors zoeken ritme, niet alleen inhoud.