Kun je de scope van een SOC2 of ISO27001 beperken?
title: "Kun je de scope van een SOC2 of ISO27001 beperken?" description: "Het korte antwoord is 'ja', maar je moet wel rekening houden met een aantal zaken. Lees verder om te ontdekken hoe je tijd en middelen kunt besparen bij het verkrijgen van een certificering." date: "2023-05-09" categories: ["Blog", "ISO27001", "SOC2"] imageUrl: "scoping.jpg" imageCredit: "Afbeeldingsbron: Bing image creator" published: true nrWords: 620 authors: ["Dennis van de Wiel"]
Wanneer je een startup of scaleup runt, groeit en verandert je bedrijf voortdurend. Je introduceert nieuwe diensten en producten, en op een gegeven moment moet je een beveiligings-/privacycertificering of -rapport verkrijgen.
Maar wat als je alleen beveiligingsmaatregelen wilt implementeren waar ze het meest nodig zijn, en je bedrijf wendbaar wilt houden waar ze niet nodig zijn? Is dat mogelijk? Kun je de scope van een SOC2 of ISO27001 proces beperken?
Het korte antwoord is 'ja, als je het goed doet'. Dus hoe werkt dat?
De casus van Un-Beat-able
Enkele jaren geleden lanceerde Un-Beat-able (fictieve casus) een muziekplatform. Dit platform werd enorm succesvol, trok veel muziekfans en kapitaal aan. Ze breidden het team en platform dienovereenkomstig uit, maar er was nooit behoefte aan een informatiebeveiliging certificering omdat het platform geen gevoelige gegevens verzamelde of integreerde met derden.
Dat veranderde allemaal toen Un-Beat-able een betaaldienst lanceerde om het platform te laten groeien. De betaaldienst, ontwikkeld door een derde partij, integreerde met een bank. Deze bank vraagt nu aan Un-Beat-able om bewijs dat ze cyberbeveiligingspraktijken hebben geïmplementeerd. Un-Beat-able overweegt ISO27001 en SOC2, maar is bang dat de bestaande organisatie zwaar zal worden beïnvloed door het audit- en certificeringsproces.
Hoe scope-bepaling werkt in ISO27001
Elke ISO27001-certificering heeft de volgende zin op de eerste pagina: "Dit certificaat is geldig voor de volgende scope: Informatiebeveiliging gerelateerd aan x." waarbij x een of meer diensten en/of producten is. Nu zouden de meeste bedrijven hun volledige lijst met diensten en producten invullen, maar dit is niet noodzakelijk.
In het geval van Un-Beat-able zouden ze ervoor kunnen kiezen om alleen hun betaaldienst op te nemen. En dit zou de toepasbaarheid van controles kunnen beperken tot de medewerkers en andere partijen die verantwoordelijk zijn voor deze dienst. Un-Beat-able zal echter via hun risicobeoordeling en controleselectie moeten aantonen dat dit inderdaad het geval is.
Hoe scope-bepaling werkt in SOC2
SOC2 scope-bepaling werkt een beetje anders. De officiële richtlijn stelt: "...trust services criteria (worden) gebruikt bij het evalueren van de geschiktheid van het ontwerp en de operationele effectiviteit van controles die relevant zijn voor de veiligheid, beschikbaarheid of verwerkingsintegriteit van informatie en systemen, of de vertrouwelijkheid of privacy van de door de systemen verwerkte informatie...".
Deze verklaring biedt twee scope-mechanismen. Ten eerste stelt het een bedrijf in staat om te selecteren welke producten of diensten binnen de scope van het rapport vallen. Ten tweede stelt het een bedrijf in staat om de criteria te selecteren die op deze dienst van toepassing zijn. Un-Beat-able kan bijvoorbeeld specificeren dat de scope van de SOC2-verklaring de beveiliging (criterium) van hun betaaldienst (gespecificeerde dienst) is.
Is scope-beperking altijd een goed idee?
Un-Beat-able opereert zijn betaaldienst op een hoger volwassenheidsniveau dan de rest van de organisatie, en een apart team heeft aan deze dienst gewerkt. Dus in dit scenario kan Un-Beat-able de tijd en middelen die nodig zijn om compliant te worden aanzienlijk verminderen. En ze kunnen de scope altijd uitbreiden in het volgende rapport.
Dit is echter niet altijd het geval. Bedrijven die over het geheel genomen op een hoger volwassenheidsniveau opereren, bijv. ze ontwikkelen software veilig by design, trainen hun medewerkers, en testen regelmatig op zwakke plekken in de informatiebeveiliging, zijn beter voorbereid en weerbaarder tegen informatiebeveiligingsrisico's. Als alternatief is het misschien niet mogelijk om de scope te beperken omdat diensten te veel met elkaar verweven zijn. In deze scenario's is er simpelweg geen toegevoegde waarde van scope-beperking, of het voordeel rechtvaardigt de kosten niet.
Conclusie
Het is mogelijk om de scope van ISO27001 en SOC2 trajecten te beperken. Het belangrijkste is om ervoor te zorgen dat de scope-beperking wordt vertaald naar je systemen, processen en mensen. Als dat het geval is, vertegenwoordigt scope-beperking een zeer effectieve manier om snel een certificering te verkrijgen zonder de bank te breken.
Geschreven door Dennis van de Wiel, Oprichter