Van controle tot continuïteit: SOC 2 audit en ISO 22301 slim combineren

In een wereld waarin compliance, security en bedrijfscontinuïteit steeds zwaarder wegen, zoeken organisaties naar raamwerken die niet alleen vertrouwen wekken bij klanten en toezichthouders, maar die ook praktisch werkbaar zijn in de dagelijkse operatie. Dat is geen overbodige nuance, want de praktijk laat regelmatig zien hoe raamwerken verworden tot papieren constructies: keurig gedocumenteerd, netjes goedgekeurd, maar zonder merkbare invloed op hoe er werkelijk wordt gewerkt. Twee standaarden die in dit gesprek vrijwel altijd op tafel komen, zijn de soc 2 audit en iso 22301. De eerste is inmiddels de standaardvraag geworden zodra een dienstverlener gegevens van een klant verwerkt of beheert, de tweede is het antwoord op een andere maar even urgente vraag: wat gebeurt er als het misgaat en de dienstverlening stilvalt?

Die twee vragen worden binnen organisaties vaak door verschillende mensen beantwoord, in verschillende trajecten, met verschillende documentatie en verschillende auditmomenten. Het security- of complianceteam werkt aan de SOC 2-rapportage omdat sales daar in verkooptrajecten om vraagt, terwijl continuïteit ergens bij operations of facility management is belegd en pas aandacht krijgt als er een storing is geweest. Het gevolg is dubbel werk, tegenstrijdige documentatie en een organisatie die op papier alles op orde heeft maar in de praktijk niet weet wie er belt wanneer het datacenter uitvalt op een zondagochtend. Dat is zonde, want de overlap tussen beide raamwerken is aanzienlijk en de onderlinge versterking is groot zodra je ze bewust naast elkaar legt.

In dit artikel lees je wat een SOC 2 audit precies inhoudt en welke criteria daarbij worden getoetst, wat ISO 22301 vraagt van een organisatie die haar continuïteit serieus neemt, waar de verschillen tussen beide zitten en waarom die verschillen juist de reden zijn dat ze elkaar zo goed aanvullen. Daarna volgt een concreet stappenplan om beide raamwerken gecombineerd op te pakken, plus antwoord op de vragen die in de praktijk het vaakst gesteld worden.

Wat is een SOC 2 audit?

De basis van SOC 2

SOC 2 staat voor System and Organization Controls 2 en is ontwikkeld door het American Institute of Certified Public Accountants. Het is geen certificering in de klassieke zin van het woord, en dat onderscheid is belangrijker dan het lijkt. Waar een ISO-norm leidt tot een certificaat dat door een geaccrediteerde instelling wordt afgegeven en dat je kunt tonen als bewijs, resulteert een SOC 2-traject in een rapport: een uitgebreide beschrijving van je systeem en je beheersmaatregelen, voorzien van het oordeel van een onafhankelijke accountant over de vraag of die maatregelen adequaat zijn opgezet en, afhankelijk van het type, ook effectief hebben gewerkt. Dat rapport bevat aanzienlijk meer informatie dan een certificaat, wat verklaart waarom klanten er zo aan hechten. Ze lezen niet alleen dát je iets doet, maar ook hoe je het doet en wat de auditor daarvan vond, inclusief eventuele afwijkingen.

Binnen SOC 2 wordt onderscheid gemaakt tussen Type I en Type II. Een Type I-rapport beoordeelt de opzet van de beheersmaatregelen op één specifiek moment: bestaan de maatregelen en zijn ze zo ingericht dat ze het beoogde doel kunnen bereiken? Een Type II-rapport gaat verder en beoordeelt of die maatregelen gedurende een langere periode, meestal zes tot twaalf maanden, ook daadwerkelijk effectief hebben gewerkt. Dat verschil is in de praktijk enorm. Bij een Type I kun je in de weken voor de audit nog het nodige rechttrekken; bij een Type II kijkt de auditor terug over een volledige periode en neemt hij steekproeven uit die hele periode. Een proces dat pas in de laatste maand goed werd uitgevoerd, valt dan onherroepelijk op. De meeste klanten die serieus naar hun leveranciers kijken, vragen dan ook expliciet om Type II en nemen genoegen met Type I hooguit als tussenstap voor een organisatie die nog maar net begonnen is.

Welke Trust Services Criteria tellen mee?

Een SOC 2-rapport is opgebouwd rond de Trust Services Criteria, vijf domeinen waarvan je er zelf een selectie maakt op basis van wat relevant is voor je dienstverlening. Security, ook wel de common criteria genoemd, is daarbij altijd verplicht en vormt het fundament: toegangsbeheer, wijzigingsbeheer, risicobeoordeling, monitoring, incidentafhandeling en de governance daaromheen. De overige vier zijn optioneel. Availability gaat over beschikbaarheid en toont aan dat je systemen bereikbaar zijn conform de afspraken die je met klanten hebt gemaakt, inclusief capaciteitsbeheer, back-ups en herstelprocedures. Processing Integrity richt zich op de vraag of gegevensverwerking volledig, juist en tijdig plaatsvindt, wat vooral relevant is voor partijen die transacties of berekeningen uitvoeren. Confidentiality gaat over informatie die contractueel of anderszins vertrouwelijk is en hoe je die beschermt en uiteindelijk vernietigt. Privacy richt zich specifiek op persoonsgegevens en de rechten van betrokkenen.

De keuze voor de juiste combinatie is een strategische afweging en geen technische. Elk extra criterium betekent meer maatregelen, meer bewijslast en een duurder traject, maar het kan ook precies de vraag beantwoorden die je grootste klanten stellen. Voor de samenhang met continuïteit is vooral Availability interessant: dat criterium raakt direct aan onderwerpen die ook in een business continuity managementsysteem thuishoren, zoals herstelprocedures, uitwijkvoorzieningen en het testen daarvan. Wie beide trajecten combineert, doet er verstandig aan die overlap bewust te benutten in plaats van hem twee keer afzonderlijk in te richten.

Voor welke organisaties is SOC 2 relevant?

SOC 2 is ontstaan in de context van serviceorganisaties en is inmiddels vrijwel de standaard geworden voor iedereen die als dienstverlener gegevens van klanten verwerkt, opslaat of beheert. SaaS-leveranciers vormen de grootste groep, maar het geldt evengoed voor cloud- en hostingpartijen, managed service providers, payrollverwerkers, datacenters en organisaties die administratieve of financiële processen uitbesteed krijgen. De onderliggende logica is eenvoudig: een klant die een kritisch proces bij jou onderbrengt, blijft zelf verantwoordelijk richting zijn eigen klanten en toezichthouders. Hij moet dus kunnen aantonen dat hij weet hoe jij die verantwoordelijkheid invult, en een SOC 2-rapport is precies het instrument dat die vraag beantwoordt zonder dat elke klant afzonderlijk bij jou op audit hoeft te komen.

Dat laatste punt is commercieel gezien vaak doorslaggevend. Zonder rapport krijg je van elke serieuze klant een uitgebreide vragenlijst, gevolgd door verdiepende vragen, gevolgd door soms een auditbezoek. Dat kost per klant tientallen uren en het schaalt niet mee met je groei. Met een actueel Type II-rapport verkort je dat traject tot het delen van één document onder geheimhouding. Voor organisaties die internationaal opereren, en zeker richting de Amerikaanse markt, is SOC 2 bovendien de taal die inkopers en security teams verwachten te spreken. In Europa staat ISO 27001 sterker, wat verklaart waarom veel organisaties uiteindelijk beide aanhouden.

Wat is ISO 22301?

Focus op business continuity management

ISO 22301 is de internationale norm voor business continuity management en beantwoordt een fundamenteel andere vraag dan SOC 2. Waar SOC 2 vooral kijkt naar of je maatregelen hebt getroffen om ongewenste gebeurtenissen te voorkomen en te beheersen, gaat ISO 22301 uit van het gegeven dat verstoringen hoe dan ook zullen plaatsvinden en richt zich op de vraag hoe je organisatie dan blijft functioneren. Dat kan gaan over een cyberaanval, maar net zo goed over de uitval van een cruciale leverancier, een brand in het kantoorpand, langdurige stroom- of netwerkuitval, extreme weersomstandigheden of het plotseling wegvallen van sleutelpersoneel. De norm is bewust breed en dreigingsonafhankelijk opgezet: je bereidt je niet voor op één specifiek scenario, maar op de gevolgen die verschillende scenario’s gemeen hebben, namelijk dat een essentieel proces of middel tijdelijk niet beschikbaar is.

Die insteek maakt de norm praktischer dan hij op het eerste gezicht lijkt. Je hoeft geen plan te schrijven voor elke denkbare ramp. Je brengt in kaart welke processen kritiek zijn, hoe lang die maximaal mogen uitvallen voordat de schade onacceptabel wordt, welke middelen die processen nodig hebben en welke alternatieven er zijn wanneer die middelen wegvallen. Of het datacenter uitvalt door brand of door een ransomware-aanval maakt voor je herstelaanpak vaak minder uit dan mensen denken; wat telt is dat je weet hoe je zonder dat datacenter verder kunt en hoe snel.

De kern van een BCMS

Het hart van een Business Continuity Management System bestaat uit twee analyses die elkaar aanvullen. De business impact analyse brengt in kaart wat de gevolgen zijn van uitval van elk bedrijfsproces, uitgedrukt in tijd en impact. Daaruit volgen de kerngetallen waar het hele systeem op steunt: de recovery time objective, oftewel hoe snel een proces weer moet draaien, en de recovery point objective, oftewel hoeveel gegevensverlies acceptabel is. Die getallen bepalen vervolgens welke technische en organisatorische voorzieningen je nodig hebt en wat die mogen kosten. Een RTO van vier uur vraagt een fundamenteel andere infrastructuur dan een RTO van drie dagen, en het is precies dit soort onderbouwing dat ontbreekt in organisaties waar continuïteit vooral op gevoel wordt geregeld. De risicobeoordeling vult dit aan door te kijken naar welke bedreigingen die kritieke processen kunnen raken en hoe waarschijnlijk die zijn.

Op basis daarvan stel je continuïteitsstrategieën en -plannen op, richt je een crisisorganisatie in met heldere rollen en escalatielijnen, en leg je vast hoe je communiceert met medewerkers, klanten, leveranciers en eventueel toezichthouders. Het onderdeel dat in de praktijk het meeste onderscheid maakt tussen organisaties die dit serieus nemen en organisaties die het afvinken, is het testen. ISO 22301 vraagt expliciet om oefeningen en tests, en om het vastleggen en verwerken van de resultaten daarvan. Een continuïteitsplan dat nooit is geoefend, is een aanname. Pas tijdens een oefening ontdek je dat het telefoonnummer in het crisisdraaiboek niet meer klopt, dat de back-up wel bestaat maar de sleutel om hem te ontsleutelen op de uitgevallen server stond, of dat niemand precies weet wie bevoegd is om de beslissing tot uitwijk te nemen.

Waarom ISO 22301 belangrijk is voor veerkracht

De waarde van ISO 22301 zit in het verschil tussen improviseren en voorbereiden. Elke organisatie komt een crisis door, de vraag is tegen welke prijs en met welke schade aan reputatie en klantrelaties. Organisaties zonder gestructureerde continuïteitsaanpak verliezen de eerste kritieke uren aan het uitzoeken van basale zaken: wie beslist er, wie belt de klanten, hebben we een geldig contract met een uitwijkpartij, waar staat de meest recente kopie van onze data. Organisaties met een werkend BCMS beginnen die uren met handelen in plaats van uitzoeken. Dat verschil is in geld uit te drukken, maar de reputatiewinst weegt vaak zwaarder: klanten vergeven een storing die professioneel wordt afgehandeld en waarover helder wordt gecommuniceerd veel eerder dan een storing waarbij ze dagenlang in het ongewisse blijven.

Daarnaast wordt continuïteit steeds vaker een expliciete eis. NIS2 stelt eisen aan bedrijfscontinuïteit en crisisbeheer voor organisaties in aangewezen sectoren, DORA doet iets vergelijkbaars voor de financiële sector met scherpe eisen aan testen en aan het beheersen van risico’s in de ICT-keten, en grote opdrachtgevers leggen hun eigen continuïteitsverplichtingen door in contracten met hun leveranciers. Een aantoonbaar ingericht BCMS is daarmee steeds vaker een voorwaarde om überhaupt mee te mogen doen.

SOC 2 audit vs. ISO 22301: de belangrijkste verschillen

Doel en scope

Het meest wezenlijke verschil zit in de gerichtheid. SOC 2 is naar buiten gericht en dient primair om een derde partij, meestal een klant of diens accountant, zekerheid te geven over de beheersmaatregelen bij een dienstverlener. Het rapport is geschreven voor die lezer en gaat over jouw systeem zoals klanten dat afnemen. ISO 22301 is naar binnen gericht en dient om je eigen organisatie weerbaar te maken; het certificaat dat eruit voortvloeit is een prettig neveneffect, maar het managementsysteem bestaat in de eerste plaats voor jezelf. Dat verschil vertaalt zich ook in de scope: bij SOC 2 baken je af rond de dienstverlening die je aan klanten levert, terwijl je bij ISO 22301 afbakent rond de processen die kritiek zijn voor het voortbestaan van je organisatie. Die twee cirkels overlappen aanzienlijk, maar ze zijn niet identiek. Je salarisadministratie valt zelden binnen de SOC 2-scope, maar hoort wel degelijk thuis in je continuïteitsanalyse.

Bewijslast en auditaanpak

Ook de aard van de toetsing verschilt. Een SOC 2-onderzoek wordt uitgevoerd door een accountant volgens attestatiestandaarden en resulteert in een oordeel met bijbehorende verantwoordelijkheid. De aanpak is sterk gericht op bewijs per beheersmaatregel: voor elke control beschrijft het rapport hoe die is opgezet en welke tests de auditor heeft uitgevoerd, inclusief de omvang van de steekproef en eventuele uitzonderingen. Die uitzonderingen komen in het rapport te staan, wat betekent dat je klanten ze lezen. Een ISO 22301-audit wordt uitgevoerd door een certificerende instelling en beoordeelt of het managementsysteem als geheel voldoet aan de eisen van de norm. De uitkomst is binair in de zin dat je het certificaat krijgt of niet, waarbij bevindingen intern worden gerapporteerd en niet openbaar met klanten worden gedeeld. Dat maakt de ISO-route in zekere zin vergevingsgezinder, terwijl SOC 2 dwingt tot een consistente uitvoering over de hele rapportageperiode.

Risico’s en bedrijfscontinuïteit

Inhoudelijk raken beide raamwerken aan risico’s, maar vanuit een andere hoek. SOC 2 beoordeelt of je een risicoproces hebt en of je maatregelen aansluiten op de geïdentificeerde risico’s, met de nadruk op het voorkómen van beveiligingsincidenten en op het beheerst herstellen daarvan. Continuïteit komt daarbij vooral aan bod als je het Availability-criterium in scope hebt, en zelfs dan blijft de diepgang beperkt tot wat nodig is om de afgesproken beschikbaarheid aan te tonen. ISO 22301 zet continuïteit juist centraal en gaat aanzienlijk dieper: kwantificeerbare hersteltijden, impactanalyses per proces, uitgewerkte scenario’s, een crisisorganisatie en een gestructureerd testprogramma. Kort gezegd toont SOC 2 aan dat je in control bent onder normale omstandigheden, terwijl ISO 22301 aantoont dat je dat ook blijft wanneer die omstandigheden wegvallen.

Waarom SOC 2 en ISO 22301 elkaar versterken

Van security controls naar continuïteitsplanning

De aansluiting tussen beide raamwerken is op verschillende punten vrijwel naadloos, en dat wordt het duidelijkst zichtbaar rond incidenten. SOC 2 vraagt om een incidentproces: detectie, registratie, beoordeling, escalatie, oplossing en evaluatie. ISO 22301 vraagt om een crisisorganisatie die in werking treedt zodra een verstoring een bepaalde omvang bereikt. Dat zijn geen twee processen maar twee niveaus van hetzelfde proces, en organisaties die ze afzonderlijk inrichten creëren precies de onduidelijkheid die je tijdens een echte verstoring niet kunt gebruiken: is dit nog een incident of al een crisis, wie neemt het over, en op welk moment? Door beide in één escalatiemodel te vatten met heldere criteria, los je dat op en voldoe je tegelijk aan beide raamwerken.

Hetzelfde geldt voor back-up en herstel. SOC 2 vraagt onder Availability of back-ups worden gemaakt en of herstel werkt. ISO 22301 vraagt of je hersteltijden aansluiten bij wat de business nodig heeft en of dat is getest. Als je de RTO’s en RPO’s uit je business impact analyse gebruikt als onderbouwing voor je SOC 2-maatregelen, heb je geen twee verhalen maar één goed onderbouwd verhaal. De restoretest die je uitvoert dient dan zowel als bewijs voor de auditor als als oefening voor je continuïteitsplan. Ook risicobeoordeling, leveranciersbeheer en wijzigingsbeheer kennen een vergelijkbare dubbelfunctie.

Meer vertrouwen bij klanten en stakeholders

Voor klanten die je serieus beoordelen, beantwoorden beide raamwerken samen een completer verhaal dan elk afzonderlijk. Het SOC 2-rapport geeft ze inzicht in hoe je hun gegevens beschermt en hoe je maatregelen in de praktijk hebben gefunctioneerd. Het ISO 22301-certificaat geeft antwoord op de vraag die daarna komt, en die in leveranciersbeoordelingen steeds prominenter wordt gesteld: wat gebeurt er met onze dienstverlening als het bij jullie misgaat? Voor organisaties die als kritieke leverancier in een keten zitten, is dat allang geen theoretische vraag meer. Toezichthouders kijken expliciet naar concentratierisico’s en naar de weerbaarheid van uitbestede processen, en die druk wordt via contracten doorgegeven aan leveranciers.

Efficiënter omgaan met audits en compliance-eisen

Het praktische argument is misschien wel het overtuigendst: gecombineerd aanpakken scheelt aanzienlijk in tijd en kosten. Beleidsstukken, risicoregisters, testverslagen, trainingsregistraties en verslagen van directiebeoordelingen kunnen in belangrijke mate dubbel dienen. Eén incidentregistratie voedt beide trajecten. Eén uitwijktest levert bewijs voor beide auditors. Eén set rollen en verantwoordelijkheden voorkomt dat medewerkers twee keer hetzelfde in verschillende woorden moeten uitleggen aan twee verschillende auditors. Daar komt bij dat de belasting op de organisatie afneemt: audits worden vooral vervelend gevonden omdat ze onvoorspelbaar veel tijd kosten van mensen die ook hun gewone werk hebben. Een gedeelde bewijsbasis met één centrale vindplaats maakt dat aanzienlijk beheersbaarder, en het maakt de kans kleiner dat je bij de tweede audit ontdekt dat je documentatie zichzelf tegenspreekt.

Praktische stappen om beide raamwerken te combineren

Stap 1: Breng overlap in kaart

Begin met een mapping in plaats van met documentatie. Zet de Trust Services Criteria die je in scope hebt naast de clausules van ISO 22301 en bepaal per onderdeel waar sprake is van dezelfde onderliggende activiteit. Je zult snel merken dat governance, risicobeoordeling, leveranciersbeheer, incidentafhandeling, back-up en herstel, en awareness in beide raamwerken terugkomen. Leg die mapping vast in één overzicht waarin per maatregel staat welke eisen ermee worden afgedekt, wie de eigenaar is en welk bewijs eruit voortkomt. Dat overzicht is later je belangrijkste werkdocument: het voorkomt dat je maatregelen dubbel inricht en het maakt direct zichtbaar wat er gebeurt als je iets wijzigt.

Stap 2: Documenteer beleid en procedures

Werk vanuit één set beleidsdocumenten die beide raamwerken bedient, in plaats van parallelle documentatiestromen. Een informatiebeveiligingsbeleid dat ook de continuïteitsuitgangspunten benoemt, een incidentprocedure die doorloopt in crisismanagement, een leveranciersbeleid dat zowel securityeisen als continuïteitseisen stelt aan kritieke partijen. Houd de documenten daarbij zo kort en concreet als de eisen toelaten. Documentatie die alleen bestaat om een auditor tevreden te stellen, wordt niet gelezen door de mensen die ernaar moeten handelen, en juist die mensen heb je nodig op het moment dat het spannend wordt. Zorg per document voor een eigenaar, een versienummer en een herzieningsmoment, want beide auditors zullen daarnaar vragen.

Stap 3: Test incident response en continuity plans

Ontwerp je testprogramma zo dat één oefening bewijs oplevert voor beide trajecten. Een realistische scenario-oefening waarin een ransomware-aanval leidt tot uitval van een kernsysteem, raakt tegelijk je detectie, je incidentproces, je escalatie naar crisismanagement, je herstelprocedures, je communicatie met klanten en je uitwijkvoorziening. Leg de uitvoering, de waarnemingen en de verbeterpunten zorgvuldig vast, inclusief de gemeten hersteltijden, en volg de verbeterpunten aantoonbaar op. Dat laatste is waar het in de praktijk misgaat: er wordt geoefend, er wordt een evaluatie geschreven, en die evaluatie verdwijnt in een map zonder dat er iets verandert. Een auditor die vraagt wat er met de bevindingen van de vorige oefening is gedaan, legt dat binnen enkele minuten bloot.

Stap 4: Train medewerkers en eigenaarschap borgen

Beide raamwerken staan of vallen bij mensen die weten wat er van hen wordt verwacht. Zorg dat elke maatregel en elk plan een aanwijsbare eigenaar heeft die begrijpt waarom het bestaat, en niet alleen een naam in een document. Train rolspecifiek: het crisisteam oefent besluitvorming en communicatie onder tijdsdruk, beheerders oefenen herstelprocedures, en de bredere organisatie moet vooral weten hoe en wanneer ze iets moeten melden. Regel daarnaast vervanging voor kritieke rollen, want een crisis houdt geen rekening met vakanties. Het is een terugkerende bevinding dat continuïteit in de praktijk afhangt van één of twee mensen die toevallig alles weten, en dat is op zichzelf een van de grootste continuïteitsrisico’s die een organisatie kan hebben.

Op één rij

• Breng bestaande controls en processen in kaart. Begin met wat er al is; in de meeste organisaties draait meer dan gedacht, alleen niet gedocumenteerd of niet consistent.

• Koppel SOC 2-eisen aan ISO 22301-processen. Leg per maatregel vast welke eisen uit beide raamwerken ermee worden afgedekt, zodat je één maatregel dubbel benut.

• Identificeer gaps in documentatie en testing. Onderscheid daarbij scherp tussen “we doen het niet” en “we doen het wel maar kunnen het niet aantonen”; die twee vragen een heel andere aanpak.

• Plan interne audits en simulaties. Combineer waar mogelijk, en plan ze ruim voor de externe audit zodat er tijd is om bevindingen echt op te lossen.

• Zorg voor periodieke evaluatie en verbetering. Bespreek beide raamwerken in dezelfde directiebeoordeling en stuur op basis van dezelfde cijfers, zodat continuïteit en security niet als losse werelden blijven bestaan.

Veelgestelde vragen

Is SOC 2 hetzelfde als ISO 22301?

Nee, ze verschillen zowel in doel als in vorm. SOC 2 levert een auditrapport op over de beheersmaatregelen van een dienstverlener, opgesteld door een accountant en bedoeld voor klanten die zekerheid nodig hebben over uitbestede processen. ISO 22301 is een certificeerbare managementsysteemnorm die zich richt op de continuïteit van je eigen organisatie. Het verschil in scope is fundamenteel: SOC 2 gaat over de dienst die je levert, ISO 22301 over het vermogen van je organisatie om te blijven functioneren. Ze overlappen wel degelijk, maar het is geen kwestie van de een in plaats van de ander.

Heb je beide nodig voor certificering of compliance?

Dat hangt volledig af van je situatie. Er is geen wet die voorschrijft dat je beide moet hebben. In de praktijk wordt de keuze vooral bepaald door wat je klanten en toezichthouders vragen. Lever je diensten aan Amerikaanse of internationale klanten die met gevoelige gegevens werken, dan is SOC 2 vaak onvermijdelijk. Val je onder NIS2 of DORA, of ben je een kritieke leverancier in een keten waar uitval directe gevolgen heeft, dan wordt aantoonbaar continuïteitsmanagement de doorslaggevende factor. Veel organisaties beginnen met wat commercieel het meest urgent is en bouwen het tweede raamwerk daar later bovenop, wat verstandig is zolang je de overlap vanaf het begin meeneemt.

Welke standaard is het belangrijkst voor SaaS-bedrijven?

Voor de meeste SaaS-bedrijven is SOC 2 het eerste dat gevraagd wordt, simpelweg omdat inkopers en security teams van klanten er expliciet om vragen tijdens verkooptrajecten. Zonder rapport loop je vertraging op of val je af. Naarmate je klantenbestand groeit en kritischer wordt, verschuift de aandacht echter naar beschikbaarheid en herstelvermogen, en dan komt ISO 22301 in beeld. Voor SaaS-partijen die bedrijfskritische processen ondersteunen, is de combinatie op termijn vrijwel altijd de logische uitkomst: het rapport opent deuren, het continuïteitsmanagement houdt ze open.

Hoeveel overlap zit er tussen beide frameworks?

De overlap is aanzienlijk, zeker wanneer je het Availability-criterium in je SOC 2-scope hebt. Governance, risicobeoordeling, incidentafhandeling, leveranciersbeheer, back-up en herstel, wijzigingsbeheer, awareness en directiebeoordeling komen in beide raamwerken terug, zij het vanuit een ander perspectief en met een andere diepgang. Een precies percentage is misleidend omdat het sterk afhangt van je scope, maar organisaties die de mapping serieus uitvoeren, ontdekken doorgaans dat een groot deel van het benodigde bewijs dubbel bruikbaar is. Waar de raamwerken uiteenlopen, is vooral bij de diepgang van continuïteit: business impact analyse, hersteltijden en scenario-oefeningen zijn typisch ISO 22301-materie.

Hoe begin je met een gecombineerde implementatie?

Begin met een nulmeting waarin je vaststelt wat er al aanwezig en aantoonbaar is, en maak vervolgens de mapping tussen beide raamwerken voordat je iets nieuws gaat schrijven. Bepaal daarna je scope voor beide, en wees daar realistisch in; te ruim beginnen is de meest voorkomende oorzaak van trajecten die stilvallen. Pak vervolgens eerst de onderdelen op die voor beide raamwerken gelden, zoals governance, risicobeoordeling en incidentmanagement, omdat je daarmee de grootste efficiencywinst pakt. Voeg daarna de raamwerkspecifieke onderdelen toe. Plan een interne audit of een gap-assessment ruim voor de externe momenten, zodat je bevindingen kunt oplossen in plaats van verklaren.

Conclusie

SOC 2 audit en ISO 22301 richten zich op verschillende doelen, maar vullen elkaar in de praktijk sterk aan. Waar SOC 2 vooral vertrouwen opbouwt door aan te tonen dat je beveiligingsmaatregelen zijn opgezet en effectief hebben gewerkt, helpt ISO 22301 je organisatie om operationeel overeind te blijven wanneer die maatregelen alsnog worden overweldigd door een verstoring. Het eerste raamwerk laat zien dat je in control bent, het tweede dat je dat blijft wanneer de omstandigheden tegenzitten. Samen vormen ze een aanzienlijk completer verhaal richting klanten, toezichthouders en je eigen directie dan elk afzonderlijk.

De belangrijkste winst zit echter niet in de documenten of de certificaten, maar in de manier waarop je ze inricht. Organisaties die beide trajecten als losse projecten behandelen, betalen twee keer voor werk dat grotendeels hetzelfde is en houden bovendien twee waarheden in stand die vroeg of laat gaan botsen. Organisaties die de overlap bewust benutten, bouwen één samenhangend systeem waarin security en continuïteit elkaar versterken: één risicobeeld, één escalatielijn, één set eigenaren en één bewijsbasis die beide auditors bedient.

Wie hiermee wil beginnen, doet er goed aan niet te starten met schrijven maar met inventariseren. Breng in kaart wat er al werkt, waar het bewijs ontbreekt en welke eisen er vanuit klanten en regelgeving concreet op je afkomen. Vanuit dat overzicht wordt de volgorde vanzelf duidelijk, en bouw je stap voor stap aan een organisatie die niet alleen aantoonbaar veilig is, maar ook aantoonbaar weerbaar.