Complementary user entity controls in SOC 2 en ISAE 3402: jouw deel van het werk

Wie een SOC 2- of ISAE 3402-rapport van een leverancier ontvangt, leest meestal het oordeel, bladert door de testresultaten en kijkt of er afwijkingen zijn gerapporteerd. Er staat nog een onderdeel in dat bijna niemand leest en dat juist over jou gaat: de complementary user entity controls, afgekort CUEC's. Dat zijn de beheersmaatregelen waarvan de serviceorganisatie aanneemt dat jij ze als afnemer zelf hebt ingericht. Het rapport zegt het er letterlijk bij: de beheersdoelstellingen of criteria worden alleen gehaald als die aannames kloppen. Wie de lijst negeert, leunt op zekerheid die er niet is.

Wat zijn CUEC's precies?

Een serviceorganisatie kan nooit het hele proces van haar klanten beheersen. Een SaaS-leverancier beheert het platform, de infrastructuur en de wijzigingen daarop, maar weet niet wie er bij jou in dienst komt of vertrekt. De leverancier kan dus onmogelijk garanderen dat alleen geautoriseerde personen van jouw organisatie toegang hebben. Dat stukje beheersing ligt bij jou.

Daarom beschrijft de serviceorganisatie in de system description van het rapport welke beheersmaatregelen zij bij de gebruikersorganisaties veronderstelt. In een SOC 2-rapport staan de CUEC's in de system description (sectie III), vaak in een aparte tabel, soms gekoppeld aan specifieke criteria. In een ISAE 3402-rapport werkt het hetzelfde, gekoppeld aan de beheersdoelstellingen. De auditor van de serviceorganisatie test die CUEC's niet. Ze vallen buiten diens oordeel. Het zijn aannames in het ontwerp van het beheersingsstelsel, geen geteste werkelijkheid.

Typische voorbeelden

De lijst verschilt per dienst, maar een aantal CUEC's komt in vrijwel elk rapport terug. Het beheer van eigen gebruikersaccounts: de afnemer bepaalt wie toegang krijgt, met welke rol, en trekt toegang tijdig in bij uitdiensttreding. De configuratie van beveiligingsopties die de klant zelf kiest, zoals het afdwingen van MFA of SSO en wachtwoordinstellingen. De juistheid en volledigheid van data die de afnemer aanlevert. Het beoordelen van rapportages of output die de dienst produceert, bijvoorbeeld het controleren van verwerkingsverslagen. En het actueel houden van contactpersonen, zodat incidentmeldingen van de leverancier bij de juiste mensen aankomen.

Let bij het lezen op de formulering. Een goede CUEC is concreet: "de gebruikersorganisatie beoordeelt maandelijks de lijst van actieve accounts". Een vage CUEC ("de gebruikersorganisatie heeft passende beveiligingsmaatregelen") is een signaal dat de serviceorganisatie verantwoordelijkheid afschuift, en dat mag je bij je leveranciersbeoordeling best benoemen.

Waarom dit voor jouw eigen audit telt

CUEC's worden concreet zodra je eigen auditor langskomt. Leunt jouw ISO 27001-certificering, DigiD-assessment of jaarrekeningcontrole op de SOC 2 of ISAE 3402 van een leverancier, dan is de standaardvraag van de auditor: heeft de organisatie de CUEC's geïdentificeerd en afgedekt? Het rapport van de leverancier stelt immers zelf dat de criteria alleen worden gehaald in combinatie met werkende user entity controls. Kun je die mapping niet laten zien, dan is het rapport voor jouw dossier maar het halve verhaal.

In third-party-risk-managementprocessen zien wij dit vaak misgaan. De inkoop- of securityafdeling vinkt af dat de leverancier een SOC 2-rapport heeft, archiveert de pdf en gaat door. Niemand heeft gecontroleerd of de veronderstelde maatregelen aan de eigen kant bestaan. Het klassieke voorbeeld: een organisatie met een keurig SOC 2-rapport van haar payrollprovider, terwijl accounts van vertrokken medewerkers maandenlang actief blijven in dat payrollsysteem. Precies het risico dat de CUEC moest afdekken.

Zo verwerk je CUEC's in de praktijk

Een werkbare aanpak bestaat uit een paar vaste stappen. Verzamel bij de jaarlijkse rapportronde de SOC 2- en ISAE 3402-rapporten van je belangrijkste leveranciers en haal per rapport de CUEC-lijst eruit. Map elke CUEC op een bestaande interne beheersmaatregel, of stel vast dat die ontbreekt. Wijs per CUEC een eigenaar aan, want "de organisatie" is geen eigenaar. Leg vast waar het bewijs van uitvoering te vinden is, zoals de periodieke accountreview of de MFA-configuratie. En herhaal dit bij elk nieuw rapport: CUEC's veranderen wanneer de dienst of het beheersingsstelsel van de leverancier verandert, en juist die wijzigingen worden gemist als de mapping een eenmalige exercitie was.

Werk je met een carve-out rapport, kijk dan ook naar de complementary subservice organization controls (CSOC's). Dat zijn de maatregelen die bij subserviceorganisaties, zoals het onderliggende cloudplatform, worden verondersteld. Ze vragen om dezelfde behandeling, alleen ligt de bal daar niet bij jou maar bij de vraag of de serviceorganisatie haar subleveranciers monitort.

Voor serviceorganisaties: schrijf CUEC's die kloppen

Ga je zelf een SOC 2- of ISAE 3402-traject in, besteed dan aandacht aan de CUEC-lijst in je system description. Elke CUEC is een aanname die het ontwerp van jouw beheersingsstelsel draagt, en reviewende klanten en hun auditors lezen die lijst kritischer dan je denkt. Houd de lijst kort en realistisch. Neem alleen maatregelen op die echt bij de klant thuishoren, formuleer ze concreet en koppel ze waar mogelijk aan de criteria of beheersdoelstellingen waarvoor ze relevant zijn. Een opgeblazen CUEC-lijst die verantwoordelijkheden naar de klant schuift oogt misschien veilig, maar roept in reviews vragen op en maakt je rapport minder bruikbaar voor je klanten. En dat rapport is uiteindelijk een verkoopdocument.

De les

Een SOC 2- of ISAE 3402-rapport is geen vrijbrief maar een taakverdeling. De serviceorganisatie laat zien wat zij beheerst, en beschrijft wat zij van jou verwacht. Behandel de CUEC-lijst daarom als een verplicht onderdeel van elke leveranciersbeoordeling: eruit halen, mappen, eigenaar toewijzen, bewijs regelen, jaarlijks herhalen. Het kost per leverancier hooguit een dagdeel en het is het verschil tussen een rapport in de la en aantoonbare beheersing van je keten.