SOC 2 voor SaaS-bedrijven: scope, hyperscalers en bewijs uit je eigen pijplijn

Bijna elk SaaS-bedrijf komt op dezelfde manier bij SOC 2 uit. Niet via een strategiesessie, maar via een security questionnaire van een prospect die groter is dan alle klanten die je tot dan toe had. Ergens halverwege die lijst staat de vraag of je een actueel SOC 2 Type II-rapport hebt. Je antwoordt nee, de deal schuift naar het volgende kwartaal, en opeens is assurance een prioriteit.

Wat SOC 2 precies is, wat er in de vier delen van het rapport staat en hoe Type I zich tot Type II verhoudt, staat in SOC 2 uitgelegd. Dit artikel gaat over de keuzes die anders uitpakken omdat je dienst multi-tenant is, op infrastructuur van iemand anders draait en meerdere keren per week naar productie gaat.

Zolang het rapport er nog niet is

Een eerste Type II-rapport is er niet binnen een kwartaal, en de deal wacht niet. Wat in de tussentijd wel werkt, is precies zijn over waar je staat: dat de scope is vastgesteld, wanneer de observatieperiode start en wanneer het rapport wordt verwacht. Inkoopafdelingen accepteren een datum vaker dan verkopers denken. Wat niet werkt, is de suggestie dat je "SOC 2 compliant" bent. Er bestaat geen SOC 2-certificaat, en de inkoper die de questionnaire uitstuurt weet dat meestal beter dan de accountmanager die hem invult.

Een readiness assessment levert in deze fase iets op dat je direct kunt gebruiken: een onderbouwd overzicht van wat er staat en wat ontbreekt. Zie audit readiness assessment voor wat zo'n beoordeling inhoudt.

De systeemgrens is de duurste beslissing

Bij een traditionele serviceorganisatie is de scope vaak vanzelfsprekend: één dienst, één verwerkingsstraat. Bij SaaS is de systeemgrens een echte keuze, en hij bepaalt de rest van het traject.

Drie vragen doen het meeste werk. Welk product zit erin? Bedrijven met een hoofdproduct en twee kleinere modules nemen soms alles mee omdat het één codebase is, terwijl klanten alleen naar het hoofdproduct vragen. Welke omgevingen zitten erin? Productie hoort er altijd bij, maar staging en ontwikkeling komen mee zodra daar klantdata of productiegeheimen staan, en dat is vaker het geval dan teams denken. En welke ondersteunende systemen raken de dienst? Je CI/CD-pijplijn, je secrets-beheer, je logplatform en je supporttooling zitten in de scope als ze toegang geven tot klantdata, ook al staan ze niet in je architectuurplaat.

De scope die je kiest komt in de systeembeschrijving te staan en is voor klanten leesbaar. Een smalle, kloppende scope is bruikbaarder dan een brede scope waarin je maatregelen niet overal even hard kunt maken. De keuze van de categorieën werkt hetzelfde: security is verplicht, de rest neem je op als je contracten daarom vragen. Wat elke categorie kost aan maatregelen en bewijslast staat in de Trust Services Criteria.

Je cloudleverancier staat in je rapport

Dit is het punt waarop SaaS-bedrijven het vaakst iets verkeerd aannemen. Je hostingpartij is een subserviceorganisatie, en je rapport moet expliciet maken hoe je daarmee omgaat. Bij de carve-out-methode blijven hun maatregelen buiten jouw rapport en verwijs je naar hun eigen assurance-rapport. Bij de inclusive-methode worden hun maatregelen in jouw rapport meegetest, wat in de praktijk alleen kan bij leveranciers die daaraan meewerken. Voor de grote cloudplatforms is carve-out de normale route. De afweging tussen beide staat in carve-out of inclusive method.

Carve-out betekent niet dat het onderwerp klaar is. Je moet aantonen dat je het rapport van je leverancier daadwerkelijk beoordeelt, dat je kijkt naar de uitzonderingen die erin staan en naar de maatregelen die zij aan jou overlaten. Het deel van de gedeelde verantwoordelijkheid dat bij jou ligt, blijft je eigen maatregel: de configuratie van je accounts, je netwerkindeling, je sleutelbeheer, wie er toegang heeft tot de console en hoe die toegang wordt ingetrokken. Datzelfde geldt voor je verdere leveranciersketen, waarover third party risk management meer zegt.

Wat je terugduwt naar de klant

De andere kant van dezelfde medaille zijn de complementary user entity controls: de maatregelen die jij van je klanten verwacht. Bij SaaS zijn dat er meestal een handvol. De klant beheert zelf zijn gebruikers en trekt accounts in bij uitdiensttreding. De klant zet meervoudige authenticatie aan als jij die niet afdwingt. De klant kiest zijn eigen rolinstellingen en autorisatiemodel.

Die maatregelen horen in het rapport te staan, want zonder hen is jouw beheersing niet compleet. Ze zijn ook commercieel nuttig: ze maken zichtbaar waar jouw verantwoordelijkheid ophoudt. Wat er precies in zo'n lijst hoort, staat in complementary user entity controls.

Bewijs uit je eigen pijplijn

Bij een Type II toetst de auditor of maatregelen gedurende de hele periode hebben gewerkt. Voor een SaaS-organisatie zit het gevoelige punt niet bij het bewijs zelf, maar bij de volledigheid van de populatie waaruit dat bewijs komt.

Neem wijzigingsbeheer. Je maatregel is dat elke wijziging aan productie via een goedgekeurde pull request loopt. De auditor vraagt dan niet om vijfentwintig goedgekeurde pull requests, maar om de volledige lijst deployments in de periode, en trekt daar zelf een steekproef uit. Als die lijst uit een systeem komt dat je zelf beheert, wil hij weten hoe hij is samengesteld en of er iets buiten om kan. Deployments die met een noodprocedure of handmatig zijn uitgevoerd, moeten in die lijst zitten. Zie wijzigingsbeheer in de IT-audit en bewijslast in een IT-audit.

Hetzelfde geldt voor toegang. De populatie is niet de exportlijst van je identiteitsprovider op de dag dat de auditor het vraagt, maar iedereen die gedurende de periode toegang had, inclusief tijdelijke accounts, servicekoppelingen en de accounts die je bij de vorige reorganisatie hebt opgeruimd. Kortlevende infrastructuur maakt dit lastiger: containers en instances die automatisch worden vervangen, laten weinig sporen na als je logs een korte bewaartermijn hebben. Bewaartermijnen die korter zijn dan de observatieperiode zijn een van de weinige problemen die je achteraf echt niet meer kunt herstellen.

Compliance-automatisering doet de helft

Tooling die controls doorlopend monitort is bij SaaS bijna standaard geworden, en terecht: het scheelt verzamelwerk en het laat afwijkingen zien terwijl de periode nog loopt in plaats van erna. Twee dingen doet het niet. Het bepaalt je scope niet, want die volgt uit je dienst en je contracten en niet uit een sjabloon. En het vervangt het oordeel van de auditor niet, want die moet zelf vaststellen dat de gegevens waarop hij steunt volledig en juist zijn. Een dashboard dat groen is omdat een koppeling stilletjes is gestopt, is een bevinding en geen bewijs.

Groeien terwijl de klok loopt

De observatieperiode valt bij snelgroeiende bedrijven samen met verandering. Je opent een tweede regio, je vervangt een leverancier, je neemt een team over. Dat maakt het rapport niet ongeldig, maar het hoort wel beschreven te zijn, en de maatregelen moeten ook na de wijziging hebben gewerkt. De praktische regel is om dit soort veranderingen bij je auditor te melden op het moment dat je ze plant.

Reken er ook op dat het niet bij één rapport blijft. Klanten verwachten elk jaar een nieuwe periode die aansluit op de vorige, zonder gat ertussen. Hoe je dat ritme inricht staat in de jaarlijkse auditcyclus, en wat de investering bepaalt in wat een SOC 2-traject kost.

Waar je begint

Begin bij het contract van de klant die om het rapport vraagt, niet bij een lijst maatregelen. Daar staat welke dienst hij afneemt, welke beschikbaarheid je hebt beloofd en welke geheimhoudings- en bewaarafspraken gelden. Die drie dingen bepalen je systeemgrens en je categorieën, en daarmee het grootste deel van de kosten. Onze aanpak en doorlooptijd staan op de pagina over de SOC 2-audit.