De system description opstellen voor SOC 2 en ISAE 3402: opbouw, valkuilen en praktijktips

Wie een SOC 2- of ISAE 3402-traject start, denkt vooral aan controls en bewijs. Maar er is één onderdeel van het rapport dat de serviceorganisatie zelf moet schrijven: de system description, in het Nederlands vaak systeembeschrijving genoemd. De auditor toetst die beschrijving en neemt er in het oordeel expliciet een uitspraak over op. Een zwakke beschrijving leidt tot vertraging, discussie met de auditor en in het ergste geval tot een aangepast oordeel. In dit artikel behandelen we de opbouw, de eisen en de fouten die wij in de praktijk het vaakst tegenkomen.

Wat is de system description en waarom is die zo belangrijk?

Een SOC 2- of ISAE 3402-rapport bestaat grofweg uit drie delen: het oordeel van de auditor, de beschrijving van het systeem door het management en het overzicht van controls met de testwerkzaamheden en resultaten. De system description is dus geen bijlage maar een kerndeel van het rapport, en het is het deel waarvoor het management de verantwoordelijkheid draagt. Dat wordt formeel bevestigd in de management assertion die bij het rapport hoort.

De auditor geeft geen oordeel over de vraag of jouw dienstverlening goed is. De auditor geeft een oordeel over drie dingen: is de beschrijving een getrouwe weergave van het systeem zoals dat is ingericht, zijn de controls geschikt ontworpen om de doelstellingen of criteria te behalen, en (bij Type II) hebben die controls gedurende de periode effectief gewerkt. De beschrijving is daarmee het referentiepunt voor alles wat volgt: wat er niet in staat, valt buiten de audit, en wat er wel in staat, moet kloppen en aantoonbaar zijn.

Wat moet erin staan?

Voor SOC 2 hanteert de AICPA beschrijvingscriteria die voorschrijven welke onderwerpen aan bod moeten komen. Voor ISAE 3402 gelden vergelijkbare eisen. In de praktijk komt het neer op de volgende onderdelen.

De dienstverlening en de grenzen van het systeem. Welke diensten lever je, aan wat voor soort klanten, en waar houdt het systeem op? Die afbakening (de boundaries) is belangrijker dan veel organisaties denken. Een SaaS-leverancier die alleen zijn productieplatform in scope neemt, moet dat expliciet maken, anders verwacht de lezer dat ook interne bedrijfsvoering of nevenproducten zijn afgedekt.

De componenten van het systeem. De beschrijving behandelt infrastructuur, software, mensen, procedures en data. Denk aan het cloudplatform waarop je draait, de architectuur op hoofdlijnen, de teams die de dienst leveren en beheren, de belangrijkste processen (wijzigingsbeheer, incidentmanagement, toegangsbeheer, back-up en herstel) en de gegevensstromen door het systeem.

Service commitments en systeemvereisten. Bij SOC 2 beschrijf je welke toezeggingen je aan klanten doet (bijvoorbeeld beschikbaarheid, vertrouwelijkheid, beveiligingsniveau) en welke eisen het systeem daarvoor moet vervullen. De Trust Services Criteria worden vervolgens tegen die commitments afgezet.

Subserviceorganisaties. Gebruik je leveranciers die een relevant deel van de dienst uitvoeren, zoals een cloudprovider of een datacenter? Dan beschrijf je per subserviceorganisatie of je de carve-out- of inclusive-methode hanteert, en welke controls je van die partij verwacht.

Complementary user entity controls. Vrijwel elke dienst leunt op maatregelen die de klant zelf moet treffen, zoals het beheren van eigen gebruikersaccounts of het correct configureren van koppelingen. Die CUEC's horen expliciet in de beschrijving, omdat het oordeel van de auditor ervan uitgaat dat de klant ze heeft ingericht.

Relevante wijzigingen en incidenten. Bij een Type II-rapport beschrijf je significante wijzigingen in het systeem gedurende de observatieperiode. Ook significante incidenten die zich in de periode hebben voorgedaan kunnen relevant zijn voor de lezer en horen dan in de beschrijving thuis.

De vijf fouten die wij het vaakst zien

Ten eerste: de beschrijving als brochure. Marketingtaal hoort er niet in. De auditor moet elke uitspraak kunnen verifiëren. Elke superlatief die je niet kunt onderbouwen, levert reviewcommentaar op.

Ten tweede: beschrijven wat er zou moeten zijn in plaats van wat er is. Wie de beschrijving baseert op beleidsdocumenten in plaats van op de werkelijke praktijk, schrijft controls op die niet of anders bestaan. Bij de test valt dat door de mand en dat leidt tot exceptions of tot een beschrijving die tijdens de audit herschreven moet worden.

Ten derde: onduidelijke boundaries. Als niet scherp is welke systemen, omgevingen en locaties in scope zijn, ontstaat discussie met de auditor over de reikwijdte van de tests, en met klanten over wat het rapport nu eigenlijk afdekt.

Ten vierde: vergeten CUEC's en subserviceorganisaties. Een beschrijving zonder CUEC's suggereert dat de serviceorganisatie alles zelf afdekt. Dat is vrijwel nooit waar, en een auditor zal erop doorvragen. Hetzelfde geldt voor cloudproviders die nergens genoemd worden terwijl de hele dienst erop draait.

Ten vijfde: de beschrijving niet onderhouden. Na jaar één wordt de beschrijving vaak hergebruikt zonder update, terwijl het systeem is veranderd: nieuwe componenten, gewijzigde processen, andere leveranciers. Een verouderde beschrijving is per definitie geen getrouwe weergave meer.

Zo pak je het opstellen praktisch aan

Begin vroeg, het liefst tijdens de readiness-fase en ruim voordat de observatieperiode start. Wijs één eigenaar aan, meestal de security officer of compliance manager, maar laat de inhoud aanleveren door de mensen die het systeem echt kennen: engineering, operations en HR. Werk vanuit de beschrijvingscriteria als checklist, zodat je geen verplicht onderdeel mist. Schrijf feitelijk en op het juiste abstractieniveau: gedetailleerd genoeg om betekenis te hebben, maar zonder configuratiedetails die elke maand wijzigen. En laat de conceptversie vroeg aan de auditor zien; een korte review vooraf voorkomt herschrijfwerk tijdens de audit.

Plan daarnaast een vast jaarlijks moment om de beschrijving bij te werken, bijvoorbeeld gekoppeld aan de start van de nieuwe observatieperiode. Wijzigingen in architectuur, leveranciers of processen verwerk je dan gestructureerd, en de management assertion die je afgeeft blijft verdedigbaar.

Conclusie

De system description is geen formaliteit maar het fundament van het rapport: het bepaalt de scope van de audit, het is het deel waarover het management zelf verantwoording aflegt, en het is wat klanten en hun accountants als eerste lezen. Wie de beschrijving feitelijk, volledig en actueel houdt, voorkomt discussie tijdens de audit en levert een rapport af dat afnemers echt kunnen gebruiken. Hulp nodig bij het opstellen of reviewen van een system description? Wij denken graag mee.