SOC 2-audit voorbereiden: stappenplan en de fouten uit het eerste jaar

Een SOC 2-audit bereid je niet voor door documenten te schrijven voor de auditor. Je bereidt hem voor door te zorgen dat op de eerste dag van de observatieperiode elke control draait, elke control een eigenaar heeft en het bewijs vanaf die dag wordt vastgelegd. Alles wat daarna nog moet worden ingericht, is in een Type II-rapport zichtbaar als periode waarin de control niet werkte.

Dit artikel beschrijft de stappen in de volgorde waarin ze de meeste tijd besparen, en per stap de fout die wij in eerste SOC 2-trajecten het vaakst tegenkomen. Wie het kader nog niet kent, leest eerst wat een SOC 2-rapport is en wie het vraagt.

Stap 1: kies de scope zo klein als je klanten toestaan

De scope bestaat uit twee beslissingen: welke Trust Services Criteria het rapport dekt en welke systemen erin zitten. Van de vijf categorieën is alleen Security verplicht. Availability neem je op als je in contracten beschikbaarheid belooft, want dan is dat de zekerheid die klanten zoeken. Confidentiality, Processing Integrity en Privacy horen er alleen bij als je dienst er direct om draait. Welke criteria per categorie gelden, staat in het artikel over de Trust Services Criteria.

De fout die wij hier het vaakst zien: drie of vier categorieën kiezen omdat het completer oogt, of omdat een salescollega het aan een prospect heeft beloofd. Elke extra categorie betekent extra criteria, extra controls en extra bewijs, gedurende de hele observatieperiode. Uitbreiden in jaar twee is eenvoudig. Afschalen in jaar een moet je aan klanten uitleggen.

De systeemgrens is de tweede beslissing en de duurdere. Welk product, welke omgevingen en welke ondersteunende systemen (deploymentpijplijn, secrets-beheer, logplatform, supporttooling) horen bij de dienst waarover het rapport gaat? Voor SaaS-diensten werkt het artikel over SOC 2 bij SaaS-bedrijven die vragen uit. Leg de uitkomst vast in een eerste versie van de systeembeschrijving, want die bepaalt straks wat de auditor wel en niet toetst.

Stap 2: doe een nulmeting voordat de klok gaat lopen

Een Type II-rapport toetst de werking van controls over een periode. Een Type I toetst alleen de opzet en het bestaan op een moment. Het verschil en de gevolgen voor de planning staan in Type I versus Type II. Voor de voorbereiding is de conclusie eenvoudig: laat de observatieperiode pas beginnen als aantoonbaar is dat de controls draaien.

De manier om dat vast te stellen is een nulmeting, als readiness assessment of als Type I-rapport. Beide dwingen de organisatie om elke control ingericht te hebben voordat de periode start. Wie die stap overslaat, ontdekt de gaten pas als de auditor ze vindt, en dan staan ze in het rapport.

De variant van deze fout die het meeste kost: de observatieperiode te vroeg laten beginnen, omdat een klant een datum wil horen. Een periode die start terwijl de helft van de controls nog wordt ingericht, levert gegarandeerd exceptions op over de eerste maanden. Een latere startdatum met een schoon rapport is voor die klant meer waard dan een vroege startdatum met een lijst bevindingen.

Stap 3: beschrijf controls zoals ze werken

Maak een overzicht van de controls die er al zijn. Veel organisaties hebben meer op orde dan ze denken: multifactorauthenticatie, codereviews, monitoring, back-ups, een incidentprocedure. Per control leg je vast wat hij inhoudt, wie hem uitvoert, hoe vaak, en welk bewijs de werking aantoont. Dat overzicht is de control matrix, het document waar de auditor mee begint.

De fout hier is controls overnemen uit een template of compliance-tool. Handig als vertrekpunt, riskant als eindpunt. De auditor toetst wat er op papier staat. Een control die belooft dat toegangsrechten maandelijks worden beoordeeld terwijl dat per kwartaal gebeurt, levert een exception op, ook al is per kwartaal voor jouw risico prima verdedigbaar. En medewerkers herkennen zich niet in processen die van buiten komen, waardoor de naleving wegzakt zodra de aandacht verslapt.

Beschrijf controls dus zoals ze werkelijk werken, of richt ze in zoals je ze beschrijft. Beide kan, maar het moet kloppen. Een kleinere set controls die aantoonbaar wordt nageleefd is meer waard dan een indrukwekkende lijst die de praktijk niet dekt.

Stap 4: dicht de gaten die een periode nodig hebben het eerst

Vergelijk de control matrix met de gekozen criteria. Gaten die wij bij eerste audits steeds terugzien: geen vastgesteld informatiebeveiligingsbeleid, geen periodieke toegangsreviews, ongedocumenteerd wijzigingsbeheer, geen incident response plan, geen formele risicobeoordeling en geen leveranciersbeoordeling.

Niet elk gat weegt even zwaar voor de planning. Een ontbrekend beleidsdocument is in een week te schrijven en vast te stellen. Een periodieke control die nog niet bestaat, moet eerst een paar keer hebben gedraaid voordat er werking is om te toetsen. Pak daarom eerst de gaten aan die een aanloop nodig hebben: toegangsreviews, risicobeoordeling, leveranciersbeoordeling en het wijzigingsproces. Het documentaire werk kan parallel, maar bepaalt de startdatum niet.

Stap 5: bouw bewijs in het proces in

Dit is de stap waar het eerste jaar op stukloopt. Een Type II-audit vraagt bewijs over de hele observatieperiode: tickets, reviews, notulen, logging, wijzigingsdocumentatie. Organisaties die pas bij de aankondiging van de audit beginnen met verzamelen, komen erachter dat bewijs van acht maanden geleden niet meer te reconstrueren is. Een toegangsreview die niet is vastgelegd, heeft voor de auditor niet plaatsgevonden.

Leg daarom bij elke periodieke control direct vast wie wat wanneer heeft gedaan, en verzamel doorlopend in plaats van achteraf. Wat de auditor van bewijs verwacht (gedateerd, herleidbaar tot een persoon, uit het systeem in plaats van nagemaakt) staat in bewijslast bij IT-audits.

Twee punten verdienen aparte aandacht. Het eerste is volledigheid van de populatie. De auditor trekt een steekproef uit alle wijzigingen, alle nieuwe medewerkers of alle incidenten in de periode, en wil eerst kunnen vaststellen dat de lijst compleet is. Een handvol goedgekeurde pull requests is geen bewijs voor het wijzigingsproces; de volledige deploymentlijst is dat wel, inclusief handmatige wijzigingen en noodwijzigingen. Het tweede zijn bewaartermijnen. Logs die dertig dagen worden bewaard terwijl de periode zes maanden duurt, zijn een gat dat achteraf niet meer te dichten is. Controleer de bewaartermijnen voordat de periode begint.

Stap 6: regel de leveranciers voordat de auditor ernaar vraagt

Vrijwel elke serviceorganisatie steunt op derden: een cloudplatform, een datacenter, een payrollverwerker, een identity provider. Per leverancier die een rol speelt in de controls binnen je scope kies je hoe hij in het rapport terechtkomt, via de carve-out of de inclusive method. Carve-out is bij hyperscalers de gebruikelijke keuze, maar sluit het onderwerp niet af. Je moet aantonen dat je die leverancier monitort: rapport opgevraagd, gelezen, beoordeeld, en de beoordeling vastgelegd.

Organisaties die hun leveranciers pas tijdens de audit in kaart brengen, ontdekken soms dat ze nooit een rapport hebben opgevraagd. Dat is direct een bevinding op de monitoringcontrols. Inventariseer daarom aan het begin van het traject, en lees in de leveranciersrapporten de complementary user entity controls: de maatregelen die de leverancier bij jou neerlegt en die dus in jouw control matrix horen. Hoe je leveranciersbeoordeling structureel inricht, staat in third-party risk management.

Stap 7: beleg eigenaarschap breder dan een persoon

In veel organisaties wordt het SOC 2-traject gedragen door een gedreven collega, vaak de CTO of een security officer. Zolang die persoon er is, loopt het. Maar controls raken de hele organisatie: HR levert bewijs van in- en uitdiensttreding, engineering draait het wijzigingsproces, management voert de risicobeoordeling uit. Als eigenaarschap niet expliciet is belegd, stokt de uitvoering bij elke vakantie of elk vertrek.

Wijs per control een eigenaar aan, maak de uitvoering onderdeel van het gewone werk en rapporteer periodiek aan het management over de status. Wijs daarnaast een aanspreekpunt aan voor de auditor, die bewijsverzoeken coördineert en interviews inplant. Zorg dat control-eigenaren weten wat een walkthrough is en welke vragen ze kunnen verwachten.

Tijdens de audit: exceptions en de managementreactie

In vrijwel elk eerste Type II-rapport staan exceptions. Dat is normaal. Wat wij afraden is de reflex om tijdens de audit over elke bevinding te onderhandelen of bewijs achteraf te willen repareren. Auditors zien dat, en het schaadt de geloofwaardigheid van het hele rapport. Een exception met een heldere managementreactie (oorzaak, herstelmaatregel, termijn) leest voor een klant beter dan een rapport dat verdacht schoon oogt.

Behandel bevindingen als input voor het volgende jaar. Dezelfde exception mag in het tweede rapport niet terugkomen; daar letten afnemers en hun accountants op. Hoe de cyclus na het eerste rapport verder loopt, staat in de jaarlijkse SOC 2-auditcyclus.

Wat de voorbereiding oplevert

Een goed voorbereid eerste traject herken je aan vier dingen: een scope die past bij wat klanten vragen, controls die kloppen met de praktijk, bewijs dat vanaf dag een wordt vastgelegd, en eigenaarschap dat niet bij een persoon ligt. Dan is SOC 2 een beheersbare jaarcyclus in plaats van een jaarlijkse krachttoer.

Secure Audit voert readiness assessments en SOC 2-audits uit. Hoe wij het traject aanpakken en waar de kosten van afhangen, staat op de pagina over de SOC 2-audit.