Moet je echt alles certificeren? De scope-gids voor SOC 2 en ISO 27001

Wat betekent 'scope' binnen SOC 2 en ISO 27001

Scope is de harde grens van wat je auditor wel en niet beoordeelt. Het maakt het verschil tussen een audit van drie maanden en één van negen maanden. Tussen tien systemen documenteren en vijftig. Scope is de hefboom die bepaalt of certificering haalbaar is met je huidige team.

Je organisatorische scope is alles wat je bedrijf doet. Je audit scope is het deel daarvan dat onder de loep ligt. Een SaaS-bedrijf met vijf producten kan kiezen om alleen het product te certificeren dat enterprise-klanten gebruiken. Dit is geen trucje—het is expliciet toegestaan door beide standaarden.

Auditors controleren of je scope-grenzen realistisch zijn. Als je claimt dat je betaalfunctie volledig geïsoleerd draait maar deze gebruikt wel je centrale database en identity provider, krijg je vragen. Scope moet technisch kloppen. Een auditor met vijf minuten infrastructuurkennis ziet door slechte afbakening heen.

Waarom organisaties hun scope beperken

Snelheid is de meest voorkomende reden. Een startup met drie maanden om certificering te halen, kan dit realiseren door scope te beperken tot het core-product dat enterprise-klanten gebruiken.

De interne werkdruk scheelt meer dan auditorkosten. Elk systeem in scope vereist documentatie, configuratie-reviews, evidence-verzameling, en training. Bij een team van tien mensen kan het verschil tussen twintig en vijftig systemen in scope het verschil zijn tussen haalbaar en onhaalbaar.

Organisaties met legacy-systemen of hybride infrastructuur beginnen met een duidelijk afgebakende scope om eerst expertise op te bouwen. Uitbreiding kan altijd later, wanneer het fundament staat.

Scoping voor SOC 2 vs ISO 27001: het fundamentele verschil

SOC 2 en ISO 27001 benaderen scoping op fundamenteel verschillende manieren. Begrijp dit verschil en je begrijpt hoe je beide effectief kunt inzetten.

SOC 2: begin bij wat je klanten belooft

SOC 2 werkt van buiten naar binnen. Je start met je service commitments: wat beloof je klanten? Een CRM-leverancier belooft dat klantgegevens beschikbaar, veilig, en vertrouwelijk blijven. Deze beloftes bepalen welke Trust Service Criteria je moet adresseren.

Vervolgens definieer je de system boundary: alle systemen, processen en mensen die nodig zijn om die beloftes waar te maken. Het sterke aan deze aanpak is dat je scope automatisch aansluit bij wat klanten willen zien. Als je alleen een security-commitment maakt, hoef je geen privacy- of availability-maatregelen te implementeren (tenzij nodig voor security).

ISO 27001: begin bij de informatie die beschermd moet worden

ISO 27001 werkt van binnen naar buiten. Je begint met: welke informatie moet ik beschermen? Voor elke asset bepaal je:

• Vertrouwelijkheid: hoe erg is het als deze informatie gelekt wordt?
• Integriteit: hoe erg is het als deze informatie onjuist blijkt?
• Beschikbaarheid: hoe erg is het als deze informatie onbereikbaar is?

Deze bedrijfsimpactanalyse bepaalt je scope. Een startup met alleen publieke content heeft weinig vertrouwelijkheidszorgen maar mogelijk grote beschikbaarheidsrisico's. Een fintech met transactiedata heeft juist enorme vertrouwelijkheids- en integriteitsrisico's.

Vanuit je informatie-assets werk je naar buiten: welke IT-systemen verwerken deze data? Welke mensen hebben toegang? Dit creëert automatisch de grenzen van je Information Security Management System. Het voordeel is dat je gefocust blijft op echte risico's in plaats van alle mogelijke maatregelen te implementeren.

Wanneer welke aanpak het beste werkt

SOC 2 werkt uitstekend voor één duidelijk product aan enterprise-klanten. ISO 27001 schittert bij complexere organisaties met meerdere producten of verschillende risicoprofielen. De informatiecentristische aanpak helpt je prioriteren.

Voor startups die beide willen: begin met ISO 27001-logica. Definieer je kritieke informatie-assets en werk daar je scope uit. Map deze vervolgens naar SOC 2 service commitments. Deze volgorde geeft je de strategische helderheid van ISO met de klantgerichte presentatie van SOC 2.

Privacy in ISO 27001: wat je niet kunt uitscopen

Hier zit een cruciaal verschil: privacy kun je uitscopen in SOC 2 door het Privacy criterium niet te selecteren, maar ISO 27001 vereist dat je voldoet aan toepasselijke wet- en regelgeving—inclusief AVG. Annex A.5.34 over privacy en bescherming van persoonsgegevens is in de praktijk moeilijk uit te scopen. Maar je hoeft hiervoor niet je hele organisatie in scope te trekken.

Behandel privacy als een apart onderwerp, net zoals SOC 2 dat doet. Voor assets die al in scope zitten—zoals je productiedatabase met klantgegevens—hoef je vaak weinig extra's te doen. Je encryptie, toegangscontroles en logging dekken zowel security als privacy af. Voeg alleen specifieke privacy-elementen toe zoals bewaartermijnen en een proces voor datasubject requests.

Voor assets die alleen relevant zijn vanwege privacy—je website met tracking, je CRM met prospect-emails—maak je een aparte risicoanalyse. Deze krijgen vaak een lage risico-inschatting omdat je geen gevoelige informatie verzamelt. Implementeer gerichte maatregelen: een privacy notice op je website, consent-tracking voor cookies, en MFA-login op je CRM. Klaar. Deze systemen hoeven niet de volle ISO 27001-behandeling te krijgen met alle Annex A maatregelen—alleen de privacy-specifieke vereisten.

Wat valt typisch binnen scope

De core applicatie is altijd in scope. Dit is wat klanten gebruiken en waar hun data doorheen stroomt. Elke poging om dit buiten scope te houden wordt direct afgeschoten door auditors.

Onderliggende infrastructuur volgt automatisch: servers, databases, load balancers, CDN's, en backup-systemen. CI/CD pipelines zijn cruciaal omdat een compromis hier direct leidt tot gecompromitteerde productie-code. Je GitHub repository, CI-systeem en deployment pipeline zitten in scope.

Mensen met toegang tot productiesystemen of klantdata zijn in scope. Dit betekent hun toegang, training, en onboarding/offboarding-processen worden beoordeeld.

Wat kan (en moet soms) buiten scope blijven

Corporate websites zonder klantdata-verwerking kunnen buiten scope. Interne tooling zonder productie-connectie blijft vaak buiten scope: HR-systemen, interne wikis, of marketing Slack-workspaces. De vraag is: heeft compromis van dit systeem impact op klantdata-veiligheid? Zo nee, dan kan het eruit.

Maar je kunt niet uitsluiten wat fundamenteel verbonden is. Je identity provider die toegang beheert tot systemen in scope, moet mee. Je monitoring systeem dat productie-metrics verzamelt, moet mee. Je incident response proces moet mee.

De grootste scoping-valkuilen die implementatie vertragen

Scope te breed maken vanuit angst verdubbelt je werk zonder toegevoegde waarde. Auditors respecteren een goed onderbouwde, beperkte scope meer dan een brede maar slordige implementatie.

Kritieke componenten vergeten kost weken vertraging. Teams vergeten vaak hun deployment pipeline, monitoring stack, of incident response tool. Halverwege de audit moet dit alsnog gedocumenteerd worden.

Scope wijzigen tijdens de audit is bijna nooit succesvol. Investeer twee dagen in grondige scope-definitie vooraf, bespaar zes weken vertraging later.

Onduidelijke scope-grenzen leiden tot eindeloze vervolgvragen. "Marketing valt buiten scope" is niet genoeg. Leg technisch uit waarom: geen toegang tot productiesystemen, data in aparte database, geen code deployment.

Impact van scope-keuzes op je timeline en kosten

Een slimme scope kan je implementatietijd halveren. Een SaaS-startup met één core product en vijftien medewerkers kan ISO 27001 halen in twaalf weken met de juiste scope. Dezelfde startup die ook hun blog, marketing automation, en analytics stack erin stopt, heeft zes maanden nodig.

De directe auditorkosten verschillen weinig—een bredere scope voegt één tot twee dagen toe. Maar de interne kosten zijn enorm. Elk extra systeem betekent documentatie schrijven, configuratie reviewen, interviews voeren, en evidence verzamelen.

Hoe bepaal je een effectieve scope in de praktijk

Start met je klantbelofte en werk achteruit. Wat beloof je klanten precies? Dat hun data veilig is? Dat je product 99,9% beschikbaar is? Deze beloftes bepalen welke informatie-assets je moet beschermen.

Maak een bedrijfsimpactanalyse: per kritieke asset, beoordeel wat er gebeurt als deze gehacked, gelekt, of vernietigd wordt. Alleen assets met significante business impact horen in scope.

Trace dataflows vanaf klantinteractie tot opslag. Waar komt data binnen? Welke systemen raken het aan? Deze visualisatie laat zien welke systemen echt in scope moeten.

Document waarom dingen buiten scope blijven net zo zorgvuldig als wat erin zit. "Marketing website valt buiten scope omdat (1) geen klantdata wordt verwerkt, (2) geen connectie met productie-infrastructuur, (3) geen toegang tot gevoelige systemen."

Praktische voorbeelden van effectieve scoping

Startup met één core SaaS product

Een analytics platform met 200 klanten en een team van 12 certificeert hun volledige stack. In scope: Next.js webapplicatie, API-layer, PostgreSQL database, AWS infrastructuur (EC2, RDS, S3), GitHub repository, GitHub Actions, Datadog monitoring, 1Password, en Google Workspace als identity provider.

Buiten scope: Framer marketing website (alleen statische content), LinkedIn company page, en Notion (geen productie-data). Totale scope: 9 systemen, 12 mensen. Certificering in 14 weken.

Hybride infrastructuur met meerdere producten

Een fintech met drie producten certificeert alleen de betaal-API. In scope: API-layer, transaction database, on-premise HSM, AWS, Kubernetes, GitLab, Jenkins, en Splunk. Teams: backend engineering (6), security (2), infrastructure (3).

Buiten scope: klant-dashboard (read-only replica), mobile app (gebruikt alleen API), marketing site. Scope: 8 systemen plus HSM-hardware, 11 mensen. Certificering in 22 weken vanwege hybride complexiteit.

Hoe Tidal Control helpt bij scope-bepaling

Het platform begint met asset-inventaris waarbij je direct een bedrijfsimpactanalyse uitvoert. Voor elke asset beantwoord je vijf vragen over vertrouwelijkheid, integriteit, beschikbaarheid, en business impact. Het systeem berekent hieruit een kritikaliteit-score: high, medium, of low risk.

Per asset voer je een risico-analyse uit waarbij Tidal suggesties doet voor passende maatregelen. Deze zijn direct gekoppeld aan ISO 27001 en SOC 2 vereisten. Je ziet per maatregel welke Annex A controls of Trust Service Criteria het afdekt. Het platform waarschuwt als je vereisten hebt gemist.

Automatische evidence-koppeling per scope-component betekent dat bewijs alleen verzameld wordt voor systemen in scope. Configureer welke AWS-services in scope zijn, en monitoring haalt automatisch alleen relevante configuraties en logs op. Dit bespaart tientallen uren handmatig screenshot-werk.

Je volgende stappen

Begin met één vraag: welke informatie zou je bedrijf in gevaar brengen als deze gelekt, vernietigd, of gemanipuleerd werd? Het antwoord bepaalt 80% van je scope-beslissingen.

Teken vervolgens je dataflows. Van klant-input tot database-opslag, van API-calls tot analytics. Elk systeem dat data aanraakt, is een scope-kandidaat. Elk systeem zonder data-connectie kan waarschijnlijk buiten scope.

Wil je zien hoe je scope zich verhoudt tot standaard implementaties in jouw sector? Neem contact op voor een scope review van 30 minuten. We laten je zien waar andere bedrijven hun grenzen trekken en hoe ze hun implementatietijd halveerden met slimme scoping.