De management assertion bij SOC 2 en ISAE 3402: wat het is en hoe je hem opstelt

Wie voor het eerst een SOC 2- of ISAE 3402-rapport doorbladert, komt vooraan in het rapport een opvallend document tegen: een verklaring die niet door de auditor is geschreven, maar door het management van de serviceorganisatie zelf. Dat is de management assertion. Veel organisaties behandelen dit als een formaliteit die de auditor wel aanlevert en de directie even ondertekent. Dat is een misvatting die tot vervelende situaties kan leiden. In dit artikel leggen we uit wat de assertion is, waarom hij bestaat, wat erin moet staan en welke fouten wij in de praktijk tegenkomen.

Wat is een management assertion?

De management assertion is een schriftelijke verklaring van het management van de serviceorganisatie waarin het management stelling neemt over drie zaken. Ten eerste: dat de systeembeschrijving (system description) in het rapport een getrouw beeld geeft van het systeem zoals dat gedurende de periode heeft gefunctioneerd. Ten tweede: dat de controls in opzet geschikt waren om de geformuleerde beheersingsdoelstellingen of criteria te behalen. Ten derde, alleen bij Type II-rapporten: dat de controls gedurende de gehele observatieperiode effectief hebben gewerkt.

De assertion is dus geen samenvatting en geen managementvoorwoord. Het is een formele stellingname waar de audit op voortbouwt. Bij SOC 2 vloeit de eis voort uit de Amerikaanse attestatiestandaarden van de AICPA, bij ISAE 3402 uit de internationale standaard zelf, die een assertion door het management verplicht stelt als onderdeel van het rapport.

Waarom bestaat de assertion? De logica van een attestatie-opdracht

Een SOC 2- of ISAE 3402-audit is een zogenoemde attestation engagement. Dat betekent dat de auditor niet zelf een beschrijving van jouw systeem opstelt en daar een oordeel over geeft, maar een oordeel geeft over een bewering die het management doet. De rolverdeling is strikt: het management is verantwoordelijk voor de systeembeschrijving, de controls en de bewering dat die kloppen. De auditor toetst die bewering en rapporteert of zij, in alle van materieel belang zijnde opzichten, juist is.

Die volgorde is geen papieren formaliteit. Zij bepaalt wie waarvoor verantwoordelijk is. Als een systeembeschrijving processen bevat die in werkelijkheid anders lopen, is dat in de eerste plaats een probleem van het management, niet van de auditor. De assertion maakt die verantwoordelijkheid expliciet en ondertekend. Daarom kan een auditor ook niet zelf de beschrijving schrijven en vervolgens goedkeuren: dan zou hij zijn eigen werk beoordelen en is de onafhankelijkheid weg.

Wat staat er concreet in?

Hoewel de exacte formulering per rapport verschilt, bevat een goede assertion steeds dezelfde bouwstenen. De verklaring benoemt het systeem en de dienstverlening waarop het rapport betrekking heeft, en de periode (Type II) of de peildatum (Type I). Vervolgens verklaart het management dat de beschrijving het systeem getrouw weergeeft, aan de hand van vaste beschrijvingscriteria: bij SOC 2 zijn dat de description criteria van de AICPA, bij ISAE 3402 de eisen uit de standaard zelf.

Daarna volgt de kern: de verklaring dat de controls geschikt ontworpen waren om de van toepassing zijnde Trust Services Criteria (SOC 2) of beheersingsdoelstellingen (ISAE 3402) te behalen, en bij Type II dat zij effectief hebben gewerkt gedurende de periode. Tot slot benoemt de assertion de inherente beperkingen: geen enkel stelsel van controls geeft absolute zekerheid, en projectie van het oordeel naar de toekomst is beperkt omdat omstandigheden veranderen.

Werk je met subserviceorganisaties, dan moet de assertion ook aansluiten op de gekozen methode. Bij de carve-out method verklaart het management dat de beschrijving de aard van de uitbestede diensten weergeeft en welke complementaire controls bij de subserviceorganisatie worden verondersteld. Ook de complementary user entity controls (CUEC's), de controls die bij jouw klanten belegd zijn, horen consistent terug te komen in beschrijving en assertion.

Wie ondertekent de assertion?

De assertion wordt ondertekend door het management van de serviceorganisatie, in de praktijk meestal de CEO, COO of de directeur die verantwoordelijk is voor de dienstverlening in scope. Soms tekent de CTO of CISO mee, omdat die het systeem inhoudelijk het beste kent. Waar het om gaat is dat de ondertekenaar daadwerkelijk bevoegd en geïnformeerd is: iemand die namens de organisatie verantwoordelijkheid kan nemen voor de juistheid van de beschrijving en de werking van de controls.

Wat wij afraden is de ondertekening delegeren aan een compliance officer of externe consultant die het traject heeft begeleid. Formeel kan de directie de voorbereiding prima laten doen door anderen, maar de verklaring zelf is een directieverantwoordelijkheid. Een bestuurder die tekent zonder de systeembeschrijving gelezen te hebben, tekent voor iets dat hij niet kent. Bij een geschil met een klant, of erger, een incident dat tot aansprakelijkheidsvragen leidt, is dat een onhoudbare positie.

Veelgemaakte fouten in de praktijk

De meest voorkomende fout is de assertion behandelen als sluitstuk. Het document wordt in de laatste week voor oplevering opgesteld, rondgestuurd en getekend, zonder inhoudelijke review. Terwijl juist de assertion het moment is waarop het management zichzelf de vraag moet stellen: klopt dit beeld van onze organisatie, en kunnen wij dit waarmaken?

Een tweede fout is inconsistentie tussen assertion, systeembeschrijving en de feitelijke scope. Wij zien assertions die een andere periode noemen dan het rapport, die diensten noemen die inmiddels zijn uitgefaseerd, of die de carve-out van een subserviceorganisatie anders beschrijven dan de systeembeschrijving doet. De auditor haalt dit er in de review uit, maar het kost tijd en wekt geen vertrouwen.

Een derde fout: tekenen terwijl er bekende problemen zijn die niet gemeld zijn. De assertion hangt samen met de letter of representation die het management aan het einde van de audit afgeeft. Wie weet dat een control een deel van de periode niet heeft gewerkt en dat niet meldt, ondertekent een verklaring die niet klopt. Exceptions zijn geen ramp; een onjuiste assertion wel.

Tot slot zien wij organisaties die de assertion elk jaar klakkeloos kopiëren. Scope, diensten, tooling en subserviceorganisaties veranderen. De assertion moet elk auditjaar opnieuw tegen de werkelijkheid worden gehouden.

Zo pak je het goed aan

Begin met de assertion aan het begin van het traject, niet aan het einde. Stel een concepttekst op zodra de scope en de systeembeschrijving vaststaan, en laat de eindverantwoordelijke bestuurder beide documenten in samenhang reviewen. Leg vast wie tekent en waarom die persoon daartoe bevoegd is. Controleer vlak voor oplevering of periode, scope, subserviceorganisaties en CUEC's in assertion en beschrijving exact overeenkomen. En bespreek intern, vóór ondertekening, of er gebeurtenissen zijn geweest die de verklaring raken: incidenten, langdurig niet-uitgevoerde controls, wijzigingen in de dienstverlening.

Zo wordt de assertion wat hij hoort te zijn: geen formaliteit, maar het moment waarop het management aantoonbaar achter zijn eigen beheersing staat. Wil je sparren over de opzet van je assertion of systeembeschrijving? Neem gerust contact op.