"Hoe doorstaan we SOC 2" is de vraag die de meeste startups voor het eerst stellen, en het eerlijke antwoord begint met het corrigeren van de aanname. SOC 2 is geen examen met een geslaagde score en het levert geen certificaat op. Een onafhankelijk accountantskantoor auditeert je beheersmaatregelen tegen de AICPA Trust Services Criteria en geeft een oordeel: een schriftelijk rapport waarin staat of de beheersmaatregelen passend zijn ontworpen en, voor het type rapport dat bijna elke koper eigenlijk wil, of ze effectief hebben gefunctioneerd over een observatieperiode. "Doorstaan" betekent dat het oordeel van de auditor onvoorwaardelijk is: geen uitzonderingen die ernstig genoeg zijn om het te kwalificeren. Alles hieronder is het proces dat een startup naar dat onvoorwaardelijke oordeel leidt, en het draait vooral om scope en discipline, niet om een checklist met codewijzigingen.
Type I versus Type II, en waarom Type II de belangrijke is
Een Type I-rapport controleert of je beheersmaatregelen op een bepaalde datum passend zijn ontworpen. Het beantwoordt de vraag: "als deze beheersmaatregelen zouden functioneren zoals beschreven, zouden ze dan voldoen aan de criteria?", maar het zegt niets over of ze in de praktijk daadwerkelijk standhielden. Een Type II-rapport controleert dezelfde beheersmaatregelen op operationele effectiviteit over een observatieperiode, meestal drie maanden voor een eerste rapport en zes tot twaalf maanden voor een verlenging. Het beantwoordt de vraag waar de beveiligingsreview van een koper echt om geeft: hielden toegangbeheer, wijzigingsbeheer en monitoring stand over een echte periode, en niet alleen op papier?
De meeste startups hebben uiteindelijk Type II nodig, omdat dat is wat inkoopafdelingen van bedrijven en beveiligingsvragenlijsten voor leveranciers steeds vaker expliciet vragen. Type I heeft nog wel een rol: het is sneller op te stellen (geen wachttijd voor een observatieperiode) en sommige startups gebruiken het als eerste bewijs om momentum te tonen aan een vroege enterprise-deal, terwijl de Type II-observatieperiode parallel loopt. Geen van beide rapporten is een certificering en geen heeft een numerieke score; de levering is een rapport met je (management) beschrijving van het systeem en de beheersmaatregelen, je verklaring, de tests en resultaten van de auditor voor Type II, en het oordeel van de auditor.
Bepaal eerst de scope: alleen Security is verplicht
SOC 2 is georganiseerd rond vijf Trust Services Categories: Security, Availability, Confidentiality, Processing Integrity en Privacy. Security, de Common Criteria (de CC-genummerde criteria, CC1 tot en met CC9), is de enige verplichte categorie; elk SOC 2-rapport bevat deze. De andere vier zijn optioneel, en een startup die standaard alle vijf in scope neemt, bouwt en documenteert vaak beheersmaatregelen die niemand heeft gevraagd.
Bepaal de scope op basis van wat de beveiligingsreviews van je kopers daadwerkelijk vragen, niet op basis van een sjabloon. Een B2B SaaS-bedrijf heeft meestal Security plus Availability (je verbindt je tot uptime) en Confidentiality (je verwerkt klantgegevens onder een NDA-achtige verplichting). Processing Integrity is vooral relevant als de kernfunctie van je systeem het verwerken van transacties is, waarbij de volledigheid en nauwkeurigheid van die verwerking de belofte van het product is, denk aan betalingen of facturering, en niet alleen "we hebben een database". Privacy is de AICPA-categorie voor verplichtingen met betrekking tot de verwerking van persoonsgegevens in je eigen privacyverklaring, iets anders dan GDPR of andere wettelijke privacywetgeving; de meeste startups voldoen aan de verwachtingen van kopers op het gebied van persoonsgegevens zonder deze categorie toe te voegen. Vraag je eerste paar enterprise-prospects wat hun beveiligingsteam voor leveranciers vereist voordat je je scope vaststelt; het is veel goedkoper om een categorie later toe te voegen dan om een onnodige categorie te hebben gedocumenteerd.
De realistische tijdlijn
Eerst komt de voorbereiding: een gap-analyse tegen de criteria die je in scope hebt genomen, het schrijven van de beleidsregels die de criteria vereisen (toegangbeheer, wijzigingsbeheer, incidentresponse en andere), en het sluiten van hiaten in je daadwerkelijke systemen (het afdwingen van MFA, het inschakelen van audit-logging, het formaliseren van een wijzigingsgoedkeuringsstap). Voor een kleine startup die een compliance-automatiseringsplatform gebruikt om bewijs en beheersmaatregelen bij te houden, duurt de voorbereiding meestal vier tot acht weken; langer als een beheersmaatregel moet worden gebouwd in plaats van alleen gedocumenteerd, zoals het opzetten van gecentraliseerde logging die eerder niet bestond.
Voor een Type II-rapport komt de observatieperiode daarna, en de duur hiervan kan niet worden ingekort door een leverancier: de beheersmaatregelen moeten gedurende een overeengekomen periode functioneren voordat de auditor ze kan testen, dus een observatieperiode van drie maanden is drie kalendermaanden, niet een verzameling bewijs die achteraf wordt samengesteld. Er is geen universele wettelijke minimumduur; de periode wordt overeengekomen met je accountantskantoor en wordt gevormd door wat de beoogde gebruikers van je rapport verwachten. Eerste rapporten dekken meestal drie tot zes maanden, verlengingen vaak zes tot twaalf maanden. Tijdens de observatieperiode moeten de beheersmaatregelen in scope consistent functioneren: een hiaat kan een gesamplede uitzondering worden, afhankelijk van de test van de auditor, de aard, frequentie en betekenis ervan, niet automatisch.
Na de observatieperiode volgt het audit-veldwerk: de auditor beoordeelt bewijs, samplet transacties en wijzigingen, voert gesprekken met de eigenaren van de beheersmaatregelen en stelt bevindingen op, meestal twee tot vier weken, waarna het definitieve rapport wordt uitgebracht. In totaal duurt het eerste Type II-rapport van een startup realistisch gezien vijf tot negen maanden van start tot rapport in handen, als typische benchmark, niet als AICPA-eis. Behandel een belofte van "SOC 2 in een maand" voorzichtig: dit betekent meestal voorbereidingswerk, een Type I-rapport of een uitzonderlijk korte rapportageperiode die een specifieke auditor heeft geaccepteerd, niet een conventioneel Type II-rapport van meerdere maanden.
Wat een observatieperiode daadwerkelijk verstoort
De observatieperiode is waar de meeste startups voor het eerst een vervelende verrassing krijgen, omdat deze lang genoeg is om normale ontwikkelwerkzaamheden stilletjes een beheersmaatregel ongedaan te maken die net in de voorbereidingsfase is ingesteld. Een pull request met één regel die een IAM-beleid verruimt naar een wildcard voor het gemak, een opschoning die de audit-logregel voor een bevoorrechte actie verwijdert, een hotfix die de gebruikelijke wijzigingsgoedkeuringsstap overslaat onder tijdsdruk: geen van deze zaken lijkt op compliance-werk terwijl ze gebeuren, en elk is precies het soort ding dat een gesamplede uitzondering kan worden als het binnen de observatieperiode valt en de test van de auditor het opmerkt. De gedetailleerde informatie over welke criteria daadwerkelijk in een diff verschijnen, voornamelijk de CC6-familie voor logische toegang plus CC7.2 voor monitoring en CC8.1 voor wijzigingsbeheer, staat in de diepgaande SOC 2-frameworkgids en de begeleidende handleiding over wat SOC 2 in je repository controleert.
Dit is de laag die een compliance-check op pull-request-niveau toevoegt tijdens de observatieperiode: het leest elke wijziging tegen de criteria die je in scope hebt genomen en noemt degene die het raakt, bijvoorbeeld CC6.1 voor het verruimde IAM-beleid, als een review-opmerking op het moment dat de wijziging wordt voorgesteld. Als het daar wordt opgemerkt, kan het team het beoordelen en oplossen voordat het ooit wordt geïmplementeerd, meestal veel goedkoper dan achteraf. Als het wordt gemist, is het een wijziging die de auditor als een uitzondering zou kunnen sampleen die je zou moeten uitleggen, wat het oordeel waar je maanden aan hebt gewerkt, kan bemoeilijken.
Wat dit niet vervangt
Een pull-request-check is één laag van een veel groter proces, en het is de moeite waard om precies te zijn over de rest, omdat geen van die onderdelen de taak van heygrc is. Het kiezen van je auditor, het bepalen van je trust-categorieën, het schrijven van je beleidsregels, het uitvoeren van de gap-analyse voor de voorbereiding, het verzamelen van bewijs over je hele stack (identiteitsprovider, cloudconfiguratie, HR-onboarding en -offboarding, leveranciersbeheer) voor de volledige observatieperiode en het uitbrengen van het oordeel: dat is allemaal het compliance-programma, meestal uitgevoerd via een platform dat hier speciaal voor is gebouwd (de gids over compliance-automatiseringsgereedschappen beschrijft deze laag) plus je auditor. heygrc is gebouwd om pull requests te lezen tegen de criteria die je hebt geselecteerd en de beheersmaatregel te benoemen die een wijziging raakt. Het voert je audit niet uit, vervangt je auditor niet en zorgt er niet zelf voor dat je een onvoorwaardelijk oordeel krijgt; het is gebouwd om het team te helpen om wijzigingen in pull requests die relevant zijn voor beheersmaatregelen vroegtijdig op te sporen, tijdens het programma, voordat ze kunnen uitgroeien tot het soort uitzondering dat het verkrijgen van het oordeel bemoeilijkt.