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

Wat scope betekent 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 3 maanden en een van 9 maanden, en tussen het documenteren van 10 systemen of 50. Scope is de hefboom die bepaalt of certificering haalbaar is met je huidige team.

Je organisatiescope is alles wat je bedrijf doet. Je auditscope is het deel daarvan dat onder de loep gaat. Een SaaS bedrijf met vijf producten kan ervoor kiezen om alleen het product te certificeren dat enterprise klanten gebruiken. Beide standaarden staan dit expliciet toe.

Auditors controleren of je scopegrenzen realistisch zijn. Als je beweert dat je betaalfunctie volledig geïsoleerd draait maar hij gebruikt je centrale database en identity provider, krijg je vragen. Scope moet technisch kloppen. Een auditor met vijf minuten infrastructuurkennis prikt 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 de scope te beperken tot het kernproduct dat enterprise klanten gebruiken. Dit is een van de hefbomen achter de snelste weg naar ISO 27001 certificering als startup.

Interne werklast bespaart meer dan auditorkosten. Elk systeem in scope vraagt om documentatie, configuratiereviews, bewijsverzameling en training. Voor 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, als de basis staat.

Scoping voor SOC 2 en 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 inzet.

SOC 2: begin bij wat je klanten belooft

SOC 2 werkt van buiten naar binnen. Je begint bij je service commitments: wat beloof je klanten? Een CRM aanbieder belooft dat klantdata beschikbaar, veilig en vertrouwelijk blijft. Deze beloftes bepalen welke Trust Service Criteria je moet adresseren. Als je niet zeker weet waar je kopers eigenlijk om vragen, dan legt wat klanten echt bedoelen als ze om SOC 2 vragen het uit.

Vervolgens bepaal je de systeemgrens: alle systemen, processen en mensen die nodig zijn om die beloftes waar te maken. De kracht van deze aanpak is dat je scope automatisch aansluit op wat klanten willen zien. Als je alleen een security commitment doet, hoef je geen privacy of availability controls te implementeren (tenzij nodig voor security).

ISO 27001: begin bij de informatie die bescherming nodig heeft

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

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

Deze business impact analyse 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 informatiemiddelen werk je naar buiten: welke IT systemen verwerken deze data? Welke mensen hebben toegang? Zo ontstaan 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 controls te implementeren. Als je nog twijfelt of je überhaupt moet beginnen, behandelt ISO 27001: wat is het en wanneer begin je? de basis.

Wanneer welke aanpak het beste werkt

SOC 2 werkt uitstekend voor één duidelijk product richting enterprise klanten. ISO 27001 komt tot zijn recht bij complexere organisaties met meerdere producten of verschillende risicoprofielen. De informatiegerichte aanpak helpt je prioriteren.

Voor startups die beide willen: begin met de ISO 27001 logica. Bepaal je kritieke informatiemiddelen en werk van daaruit je scope uit. Koppel deze daarna aan 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 uit scope kunt halen

Hier zit een cruciaal verschil: in SOC 2 kun je privacy buiten scope houden door het Privacy criterium niet te selecteren, maar ISO 27001 verplicht je te voldoen aan toepasselijke wet- en regelgeving, inclusief GDPR. Annex A.5.34 over privacy en bescherming van persoonsgegevens is in de praktijk lastig buiten scope te houden, tenzij je aantoonbaar kunt laten zien dat je geen persoonsgegevens verwerkt. Maar je hoeft hiervoor niet je hele organisatie in scope te brengen.

Behandel privacy als apart onderwerp, net zoals SOC 2 doet. Voor assets die al in scope zitten, zoals je productiedatabase met klantdata, hoef je vaak weinig extra te doen. Je encryptie, toegangscontroles en logging dekken zowel security als privacy. Voeg alleen specifieke privacy elementen toe zoals bewaartermijnen en een proces voor verzoeken van betrokkenen.

Voor assets die alleen vanwege privacy relevant zijn, zoals je website met tracking of je CRM met prospect emails, maak je een aparte risicoanalyse. Deze krijgen vaak een lage risicobeoordeling omdat je geen gevoelige informatie verzamelt. Implementeer gerichte controls: een privacyverklaring op je website, consent tracking voor cookies en MFA login op je CRM. Klaar. Deze systemen hebben niet de volledige ISO 27001 behandeling met alle Annex A controls nodig, alleen de privacy specifieke eisen.

Wat doorgaans binnen scope valt

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

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

Mensen met toegang tot productiesystemen of klantdata zitten in scope. Dat betekent dat hun toegang, training en onboarding/offboarding processen worden beoordeeld.

Wat buiten scope kan (en soms moet) blijven

Corporate websites zonder verwerking van klantdata kunnen buiten scope blijven. Interne tooling zonder productiekoppeling blijft vaak buiten scope: HR systemen, interne wiki's of marketing Slack workspaces. De vraag is: heeft compromittering van dit systeem impact op de veiligheid van klantdata? Zo nee, dan kan het eruit.

Maar je kunt niet uitsluiten wat fundamenteel verbonden is. Je identity provider die toegang tot in-scope systemen beheert moet erbij. Je monitoringsysteem dat productiemetrics verzamelt moet erbij. Je incident response proces moet erbij.

De grootste scoping valkuilen die implementatie vertragen

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

Kritieke onderdelen 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 lukt bijna nooit. Investeer twee dagen in een grondige scopedefinitie vooraf, bespaar later zes weken vertraging.

Onduidelijke scopegrenzen 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.

Dit zijn niet de enige valkuilen. De 7 grootste ISO 27001 valkuilen behandelt de rest.

Impact van scopekeuzes op je tijdlijn en kosten

Een slimme scope kan je implementatietijd halveren. Een SaaS startup met één kernproduct en ongeveer 25 medewerkers kan ISO 27001 in twaalf weken halen met de juiste scope.

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 afnemen en bewijs verzamelen. Voor een volledig overzicht van wat certificering echt kost, zie ISO 27001 kosten: wat kost certificering je organisatie echt?.

Hoe je in de praktijk een effectieve scope bepaalt

Begin bij je klantbelofte en werk terug. Wat beloof je klanten precies? Dat hun data veilig is? Dat je product 99,9% beschikbaar is? Deze beloftes bepalen welke informatiemiddelen je moet beschermen.

Maak een business impact analyse: beoordeel per kritiek asset wat er gebeurt als het gehackt, gelekt of vernietigd wordt. Alleen assets met significante bedrijfsimpact horen in scope.

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

Documenteer waarom dingen buiten scope blijven net zo zorgvuldig als wat erin zit. "Marketingwebsite valt buiten scope omdat (1) er geen klantdata wordt verwerkt, (2) er geen koppeling is met productie-infrastructuur, (3) er geen toegang is tot gevoelige systemen."

Praktijkvoorbeelden van effectieve scoping

Startup met één kern SaaS product

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

Buiten scope: Framer marketingwebsite (alleen statische content), LinkedIn bedrijfspagina en Notion (geen productiedata). Totale scope: 9 systemen, 12 mensen. Certificering behaald in 14 weken.

Hybride infrastructuur met meerdere producten

Een fintech met 3 producten certificeert alleen de payment API. In scope: API laag, transactiedatabase, on-premise HSM, AWS, Kubernetes, GitLab, Jenkins en Splunk. Teams: backend engineering (6), security (2), infrastructuur (3).

Buiten scope: klantdashboard (read-only replica), mobiele app (gebruikt alleen de API), marketingsite. Scope: 8 systemen plus HSM hardware, 11 mensen. Certificering in 22 weken door de hybride complexiteit.

Hoe Tidal Control helpt bij scopebepaling

Het platform begint met een asset inventarisatie waarin je direct een business impact analyse uitvoert. Voor elk asset beantwoord je vijf vragen over vertrouwelijkheid, integriteit, beschikbaarheid en bedrijfsimpact. Tidal neemt de hoogste van de drie scores als impactniveau van het asset.

Per asset voer je een risicoanalyse uit waarbij Tidal passende controls voorstelt. Deze zijn direct gekoppeld aan ISO 27001 en SOC 2 eisen. Je ziet per control welke Annex A controls of Trust Service Criteria het afdekt. De ingebouwde tests van Tidal signaleren onvolledige risicobeoordelingen en assets zonder eigenaar.

Tests kunnen aan controls gekoppeld worden, en aan assets. Zo tel je je in-scope systemen. Tests lezen security relevante informatie en bewijs automatisch uit je cloud en IT systemen. Daarnaast heeft Tidal tests binnen het platform om je algehele compliance positie bij te houden. Dit bespaart tientallen uren handmatig screenshot- en zoekwerk.

Veelgestelde vragen

Kun je je marketingwebsite buiten scope houden? Ja, als hij geen klantdata verwerkt en geen koppeling heeft met productie-infrastructuur. Documenteer de onderbouwing expliciet: geen dataverwerking, geen gedeelde credentials, geen code deployment pad.

Kun je privacy buiten de scope van ISO 27001 houden? Niet op dezelfde manier als bij SOC 2. ISO 27001 vereist naleving van toepasselijke wetgeving inclusief GDPR, dus Annex A.5.34 is lastig uit te sluiten tenzij je aantoonbaar kunt laten zien dat je geen persoonsgegevens verwerkt.

Kun je privacy buiten scope houden bij SOC 2? Ja. Privacy is een van de vijf Trust Service Criteria, en je selecteert het simpelweg niet als je geen privacy commitment aan klanten hebt gedaan.

Kun je je scope halverwege de audit wijzigen? Bijna nooit met succes. Investeer vooraf tijd in een grondige scopedefinitie in plaats van grenzen aan te passen als de audit al gestart is, want dat zorgt meestal voor weken vertraging.

Je volgende stappen

Begin met één vraag: welke informatie zou je bedrijf in gevaar brengen als het zou uitlekken, vernietigd of gemanipuleerd worden? Het antwoord bepaalt 80% van je scopebeslissingen.

Teken daarna letterlijk je dataflows. Van klantinput tot databaseopslag, van API calls tot analytics. Elk systeem dat data aanraakt is een scopekandidaat. Elk systeem zonder datakoppeling kan waarschijnlijk buiten scope blijven.

Zodra je grenzen helder zijn, loopt je ISO 27001 traject plannen de tijdlijn door van kick-off tot certificaat.

Benieuwd hoe jouw scope zich verhoudt tot standaard implementaties in je sector? Plan een kennismakingsgesprek met ons compliance team, of doe eerst de gratis quick scan.