Tag: SOC 2

  • SOC 2, ISO 27001 of ISAE 3402: wat vraagt je klant nu eigenlijk van je?

    SOC 2, ISO 27001 of ISAE 3402: wat vraagt je klant nu eigenlijk van je?

    Een klant stelt een ogenschijnlijk eenvoudige vraag:

    “Hebben jullie ISO 27001?”
    of
    “Kunnen jullie een SOC 2 rapport delen?”

    Op het eerste gezicht lijkt het duidelijk wat er gevraagd wordt. Toch is dat in de praktijk zelden het geval.

    De vraag gaat namelijk meestal niet over een specifiek certificaat of rapport, maar over vertrouwen. Alleen wordt dat vertrouwen vaak vertaald naar termen die niet precies aansluiten bij wat de klant daadwerkelijk probeert te toetsen. En juist daar ontstaan keuzes die achteraf niet goed blijken te passen.

    De vraag achter de vraag

    Wanneer een klant vraagt om ISO 27001, SOC 2 of ISAE 3402, probeert hij in de meeste gevallen één van drie dingen duidelijk te krijgen: of je zorgvuldig met informatie omgaat, of je interne beheersmaatregelen daadwerkelijk werken, of dat hij jouw processen veilig kan opnemen in zijn eigen keten.

    Dat zijn wezenlijk verschillende vragen. Toch zie je in de praktijk dat organisaties ze vaak op dezelfde manier beantwoorden, namelijk door te kijken welk certificaat of rapport ze nodig hebben. Daarmee verschuift de focus van de onderliggende behoefte naar de vorm waarin die behoefte wordt uitgedrukt.

    Het gevolg is dat trajecten worden gestart die óf zwaarder zijn dan nodig, óf onvoldoende aansluiten op wat de klant eigenlijk wil weten.

    Wat deze vormen van assurance écht betekenen

    Hoewel de termen vaak door elkaar worden gebruikt, verschillen ze inhoudelijk behoorlijk van elkaar.

    ISO 27001 is een certificering van een managementsysteem voor informatiebeveiliging. Het laat zien dat je structureel risico’s identificeert, passende maatregelen neemt en blijft verbeteren. Daarmee zegt het vooral iets over hoe je organisatie als geheel is ingericht en hoe je omgaat met informatiebeveiliging.

    SOC 2 heeft een andere insteek. Dit is geen certificaat, maar een assurance-rapport waarin een auditor beoordeelt hoe interne beheersmaatregelen zijn ingericht en functioneren. Daarbij is het onderscheid tussen Type I en Type II relevant. Een Type I-rapport kijkt naar de opzet van maatregelen op een bepaald moment, terwijl een Type II-rapport ook beoordeelt of die maatregelen over een langere periode aantoonbaar hebben gewerkt. De nadruk ligt daarmee meer op werking dan alleen op inrichting.

    ISAE 3402 richt zich weer op een ander vraagstuk. Deze rapportage is bedoeld voor situaties waarin een organisatie processen uitvoert die onderdeel zijn van de interne beheersing van haar klant. Denk aan uitbestede processen die invloed hebben op bijvoorbeeld financiële verslaggeving of operationele controles. In zo’n geval wil de klant zekerheid over hoe die processen zijn ingericht en functioneren, omdat hij daar zelf op moet kunnen steunen.

    Waarom deze begrippen door elkaar lopen

    In de praktijk zie je dat organisaties een klantvraag vaak direct vertalen naar een oplossing. Er wordt gevraagd om zekerheid, dus er wordt gedacht aan een certificaat of assurance-rapport.

    Die stap is begrijpelijk, maar vaak te snel.

    Een klant die om ISO 27001 vraagt, wil in veel gevallen simpelweg zeker weten dat informatiebeveiliging serieus en structureel wordt aangepakt. Een vraag naar SOC 2 kan voortkomen uit de behoefte om te zien dat maatregelen niet alleen bestaan, maar ook daadwerkelijk werken. En soms ligt de vraag nog een laag dieper, bijvoorbeeld wanneer een klant wil begrijpen wat er precies gebeurt in een proces dat hij aan jou uitbesteedt.

    Als je die onderliggende bedoeling niet scherp hebt, is de kans groot dat je optimaliseert voor de verkeerde uitkomst.

    De stap die vaak wordt overgeslagen

    Wat in dit soort situaties vaak ontbreekt, is een eenvoudige maar cruciale stap: doorvragen naar de bedoeling achter de vraag.

    Niet welk rapport of certificaat gewenst is, maar welk risico de klant probeert af te dekken en waar hij zekerheid over wil krijgen. In veel gevallen blijkt dat de oorspronkelijke vraag slechts een afgeleide is van een bredere zorg.

    Door dat gesprek te voeren, ontstaat vaak meer ruimte. Soms blijkt een lichtere vorm van bewijs voldoende. In andere gevallen wordt juist duidelijk dat een zwaardere vorm van assurance wél nodig is, maar dan met een heldere reden.

    Wanneer kies je wat?

    De keuze voor ISO 27001, SOC 2 of ISAE 3402 ontstaat idealiter pas nadat duidelijk is wat er precies wordt gevraagd.

    ISO 27001 past wanneer je wilt laten zien dat informatiebeveiliging structureel is ingericht en geborgd in je organisatie.

    SOC 2 is logischer wanneer je moet aantonen dat interne beheersmaatregelen niet alleen bestaan, maar ook aantoonbaar werken over een bepaalde periode.

    ISAE 3402 komt in beeld wanneer jouw processen onderdeel zijn van de controleomgeving van je klant en hij daar expliciet zekerheid over nodig heeft.

    De keuze zelf is dus minder ingewikkeld dan hij vaak lijkt. De complexiteit zit vooral in het goed begrijpen van de vraag die eraan voorafgaat.

    De valkuil van “meer is beter”

    Een veelgemaakte aanname is dat meer bewijs automatisch leidt tot meer vertrouwen. In dat denken voelt een combinatie van certificaten en rapportages al snel als de veilige keuze.

    In de praktijk werkt dat vaak anders.

    Zwaardere trajecten brengen meer auditdruk met zich mee, vragen meer onderhoud en maken processen complexer. Als die extra inspanning niet direct aansluit op wat de klant wil weten, levert het weinig op en kan het zelfs averechts werken.

    Vertrouwen ontstaat niet door de hoeveelheid bewijs, maar door de aansluiting ervan op de vraag.

    Structuur vóór certificering

    Veel organisaties beginnen bij de vorm: welk certificaat of welk rapport is nodig?

    Een sterkere aanpak begint eerder, namelijk bij de onderliggende structuur.

    Welke risico’s spelen er? Welke maatregelen zijn getroffen? Wie is waarvoor verantwoordelijk? En hoe wordt zichtbaar dat maatregelen daadwerkelijk werken?

    Wanneer die basis helder is, volgt de keuze voor een passende vorm van assurance bijna vanzelf. Zonder die basis wordt elk traject zwaarder, omdat het moet compenseren voor onduidelijkheid die eerder al aanwezig was.

    Wat klanten uiteindelijk willen zien

    Uiteindelijk zoeken klanten geen norm op zichzelf. Ze zoeken voorspelbaarheid.

    Ze willen begrijpen wat er gebeurt, waar risico’s zitten en hoe daarmee wordt omgegaan. Een certificaat of rapport is een manier om dat inzicht te geven, maar blijft altijd een middel.

    Niet het doel.

    Tot slot

    De vraag is dus niet zozeer of je ISO 27001 nodig hebt of een SOC 2 rapport moet laten opstellen.

    De relevantere vraag is wat je klant eigenlijk probeert zeker te weten.

    Wie dat scherp krijgt, voorkomt dat compliance een doel op zich wordt en maakt keuzes die passen bij de werkelijkheid in plaats van alleen bij de formulering van de vraag.

    Verder lezen

    Wil je dit onderwerp verder verdiepen?

  • SOC 2, ISO 27001 of ISAE 3402: wat vraagt je klant nu eigenlijk van je?

    SOC 2, ISO 27001 of ISAE 3402: wat vraagt je klant nu eigenlijk van je?

    Steeds vaker krijgen organisaties vragen van klanten over security, audits of compliance. Soms heel concreet, bijvoorbeeld:

    “Hebben jullie ISO 27001?”
    “Kunnen jullie een SOC 2 rapport delen?”
    “Hebben jullie een ISAE 3402 verklaring?”

    Voor veel organisaties voelt zo’n vraag als het begin van een zwaar traject. Certificering, audits, rapportages. Maar voordat je zo’n traject start, is het verstandig om eerst een andere vraag te stellen:

    Wat probeert de klant eigenlijk zeker te weten?

    Want in de praktijk blijkt vaak dat de vraag en de bedoeling niet hetzelfde zijn.

    Waarom klanten steeds vaker om assurance vragen

    Organisaties worden steeds afhankelijker van software, platforms en externe dienstverleners. Data wordt gedeeld, systemen worden gekoppeld en processen worden soms zelfs volledig uitbesteed.

    Wanneer een organisatie een deel van haar bedrijfsvoering afhankelijk maakt van een leverancier, ontstaat er een logisch risico. Als die leverancier fouten maakt, onvoldoende beveiligd is of processen niet goed beheerst, kan dat direct gevolgen hebben voor de klant.

    Daarom vragen steeds meer organisaties om bewijs dat processen en beveiliging onder controle zijn.

    Die vragen gaan meestal over drie onderwerpen: informatiebeveiliging, betrouwbaarheid van processen en continuïteit van dienstverlening.

    Opvallend genoeg gaat de vraag van een klant zelden echt over een specifieke norm. In de kern gaat het meestal om iets anders:

    Kunnen we erop vertrouwen dat jullie je zaken aantoonbaar op orde hebben?

    Verschillende vormen van certificering en assurance proberen dat vertrouwen op verschillende manieren zichtbaar te maken.

    ISO 27001: certificering van een managementsysteem

    ISO 27001 is een internationaal erkende norm voor informatiebeveiliging. De norm beschrijft hoe organisaties hun beveiliging structureel organiseren via een Information Security Management System (ISMS).

    Zo’n managementsysteem omvat onder andere een risicoanalyse, gekozen beveiligingsmaatregelen, beleid en procedures, monitoring en continue verbetering.

    Tijdens een certificeringstraject toetsen auditors of deze structuur daadwerkelijk functioneert. Zij kijken bijvoorbeeld naar de manier waarop risico’s worden geïdentificeerd, hoe maatregelen worden gekozen en beheerd, hoe incidenten worden opgevolgd en hoe verbeteringen worden doorgevoerd.

    Een risicoanalyse vormt daarbij een belangrijke basis voor het bepalen van passende beveiligingsmaatregelen.

    Het resultaat van een ISO 27001 traject is een certificaat, met jaarlijkse audits om te controleren of het managementsysteem blijft functioneren.

    ISO 27001 laat daarmee zien dat een organisatie informatiebeveiliging niet incidenteel regelt, maar structureel organiseert.

    Wie meer wil weten over hoe zo’n managementsysteem werkt, kan ook lezen: Wat is een ISMS en waarom is het belangrijk voor jouw bedrijf.

    SOC 2: assurance over interne controles

    SOC 2 is een assurance-raamwerk dat veel wordt gebruikt door technologiebedrijven en dienstverleners, vooral wanneer zij internationale klanten bedienen.

    In tegenstelling tot ISO 27001 is SOC 2 geen certificering, maar een auditrapport dat wordt opgesteld door een onafhankelijke auditor.

    De beoordeling is gebaseerd op de Trust Services Criteria, waaronder security, beschikbaarheid, vertrouwelijkheid, privacy en processing integrity.

    Tijdens een SOC 2 onderzoek beoordeelt een auditor of de interne controles van een organisatie passend zijn ingericht en of zij daadwerkelijk functioneren.

    Er bestaan twee varianten.

    SOC 2 Type I

    Beoordeelt of de controles op een bepaald moment goed zijn ingericht.

    SOC 2 Type II

    Beoordeelt ook of deze controles daadwerkelijk hebben gewerkt over een langere periode, meestal zes tot twaalf maanden.

    Het resultaat is een assurance-rapport dat organisaties kunnen delen met klanten en partners.

    Waar ISO 27001 een managementsysteem certificeert, rapporteert SOC 2 vooral over de opzet en werking van interne controles binnen de gekozen scope.

    ISAE 3402: assurance over uitbestede processen

    ISAE 3402 komt vooral voor bij organisaties die processen uitvoeren namens hun klanten.

    Denk bijvoorbeeld aan payroll-providers, administratieve dienstverleners of platforms die financiële processen ondersteunen.

    Het doel van een ISAE 3402 rapport is om aan te tonen dat de interne controles rond deze dienstverlening betrouwbaar functioneren.

    Dit is vooral relevant wanneer de dienstverlening invloed heeft op de financiële controleomgeving of financiële verslaggeving van de klant.

    Net als bij SOC 2 bestaan er twee varianten.

    Type I

    Een beoordeling van de opzet van het controlesysteem op een bepaald moment.

    Type II

    Een beoordeling van de werking van die controles over een langere periode.

    ISAE 3402 richt zich daarmee minder op informatiebeveiliging als geheel en meer op de betrouwbaarheid van processen die organisaties namens hun klanten uitvoeren.

    Waarom deze vragen vaak door elkaar lopen

    In de praktijk worden deze begrippen regelmatig door elkaar gebruikt.

    Een klant vraagt bijvoorbeeld om SOC 2 terwijl hij eigenlijk zekerheid wil over informatiebeveiliging. Een contract noemt ISAE 3402 terwijl het vooral over IT-security gaat. En soms vraagt een organisatie om ISO 27001 omdat dat de bekendste norm is.

    Dat gebeurt om verschillende redenen. Compliance-eisen worden vaak overgenomen uit bestaande contracten. In andere gevallen worden voorwaarden gekopieerd uit sectoren waar andere assurance-vormen gebruikelijk zijn. En soms weten klanten zelf niet precies welk type bewijs ze eigenlijk nodig hebben.

    Het gevolg is dat organisaties soms een zwaar traject starten voor een vraag die eigenlijk anders bedoeld was.

    Hoe bepaal je wat werkelijk nodig is

    De keuze tussen ISO 27001, SOC 2 of ISA 3402 hangt sterk af van de context waarin een organisatie opereert.

    ISO 27001 past goed wanneer je informatiebeveiliging structureel wilt organiseren en meerdere klanten zekerheid verwachten over security.

    SOC 2 komt vaker voor wanneer je internationale klanten bedient en klanten expliciet vragen om assurance-rapporten over interne controles.

    ISAE 3402 wordt vooral relevant wanneer je processen uitvoert die invloed hebben op de financiële controle van je klanten.

    Het doel is niet om zoveel mogelijk certificeringen of audits te verzamelen.

    Het doel is om het juiste bewijs te leveren voor de vraag die werkelijk wordt gesteld.

    Wat veel organisaties te laat ontdekken

    Veel organisaties starten een traject omdat één klant ernaar vraagt, een tender het noemt of omdat een certificering professioneel klinkt.

    Pas later blijkt dat de vraag eigenlijk anders bedoeld was, dat een lichter traject voldoende was geweest of dat de interne structuur nog niet klaar was voor zo’n audit.

    Daarom is de belangrijkste vraag vooraf niet:

    “Welke norm moeten we halen?”

    Maar:

    “Welk vertrouwen probeert de klant eigenlijk te krijgen?”

    Wanneer je dat helder hebt, kun je gerichter bepalen welke vorm van certificering of assurance daarbij past.

    Structuur vóór certificering

    Organisaties die starten met ISO-, SOC- of assurance-trajecten ontdekken vaak dat dezelfde basis nodig is.

    Risico’s moeten worden geïdentificeerd.
    Beheersmaatregelen moeten worden vastgelegd.
    Audits moeten worden uitgevoerd.
    Verbeteringen moeten worden opgevolgd.

    Wanneer die structuur ontbreekt, verandert compliance al snel in administratief werk.

    In CompliTrack komen risico’s, maatregelen, audits en verbeteracties samen in één overzichtelijke structuur. Daardoor ontstaat het inzicht dat nodig is voor certificeringen en assurance-trajecten, zonder dat organisaties hun processen onnodig hoeven te verzwaren.

    Verder lezen

    Wil je dieper ingaan op onderwerpen uit deze blog, dan zijn deze artikelen ook relevant:

  • Waarom klanten steeds vaker om SOC 2 vragen

    Waarom klanten steeds vaker om SOC 2 vragen

    En wat ze eigenlijk willen weten

    Het begint zelden met een audit.

    Meestal begint het met een goed gesprek. Een offerte die inhoudelijk klopt. Een samenwerking die logisch voelt. Vertrouwen, aan beide kanten. Tot er aan het einde van het gesprek nog één vraag op tafel komt.

    “Kunnen jullie iets delen over SOC 2?”

    De vraag klinkt vaak achteloos. Alsof het een formaliteit is. Maar de impact ervan is dat zelden. Want zodra die vraag gesteld wordt, verandert het gesprek. Niet omdat iemand direct een rapport verwacht, maar omdat er iets anders wordt aangeraakt: beheersing, verantwoordelijkheid en volwassenheid.

    Steeds meer organisaties krijgen deze vraag. Ook organisaties zonder grote compliance-afdeling of formele auditstructuur. SOC 2 schuift het gesprek binnen. Niet als certificering, maar als signaal.

    Het hardnekkige misverstand rond SOC 2

    De eerste reflex is vaak defensief.

    Dat SOC 2 “iets is voor grote techbedrijven”. Dat er geen verplichting bestaat. Dat bestaande certificering voldoende zou moeten zijn.

    Die reacties zijn begrijpelijk en vaak inhoudelijk juist. Maar ze missen de kern van de vraag. In de praktijk vragen klanten zelden om SOC 2 omdat zij diepgaande normkennis hebben. Ze vragen ernaar omdat hun afhankelijkheid toeneemt.

    Van systemen. Van processen. Van de manier waarop mensen beslissingen nemen.

    De SOC 2-vraag is zelden normgedreven. Ze is contextgedreven.

    Wat klanten eigenlijk willen weten

    Achter de vraag naar SOC 2 zitten nauwelijks abstracte compliance-eisen. Wat eronder ligt, is concreter en menselijker.

    Klanten willen begrijpen wat er gebeurt als het misgaat. Of duidelijk is wie verantwoordelijkheid draagt. Of incidenten worden vastgelegd in plaats van alleen opgelost. Of beleid iets is dat leeft in de organisatie, of alleen zichtbaar wordt wanneer iemand erom vraagt.

    Het zijn geen auditvragen. Het zijn vertrouwensvragen.

    Dat patroon is niet nieuw. Het kwam eerder terug in verhalen waarin alles op papier geregeld leek, tot een klant om bewijs vroeg. Dan bleek hoe dun de onderliggende structuur eigenlijk was. Niet omdat mensen hun werk niet deden, maar omdat niemand had vastgelegd dát het werk gedaan werd.

    SOC 2 als assurance, niet als vinkje

    SOC 2 is geen certificaat dat je behaalt en vervolgens archiveert. Het is een vorm van assurance. Dat verschil is essentieel.

    Een certificering zegt iets over voldoen op een moment. Assurance laat zien hoe een organisatie structureel werkt en hoe dat te toetsen is.

    Daar wringt het vaak. Niet omdat maatregelen ontbreken, maar omdat beheersing impliciet is georganiseerd. Taken worden uitgevoerd, maar niet herhaalbaar ingericht. Rollen zijn logisch, maar nergens expliciet vastgelegd. Incidenten worden opgelost, maar zelden geëvalueerd.

    In eerdere blogs over audits die nét niet lukten werd dit zichtbaar. De intentie was goed. De maatregelen bestonden. Maar zonder aantoonbaarheid blijft vertrouwen kwetsbaar.

    Waarom deze vragen juist nu vaker op tafel komen

    De omgeving is veranderd. Organisaties zijn sterker met elkaar verweven geraakt. Diensten zijn minder tastbaar. Afhankelijkheden zijn complexer geworden.

    Wat vroeger intern bleef, raakt nu direct anderen. Klanten kijken niet alleen meer naar het eindresultaat, maar ook naar de manier waarop dat resultaat tot stand komt.

    Daarom zie je dezelfde beweging op meerdere plekken terug. Meer aandacht voor leveranciersbeoordeling. Meer vragen over incidentbeheer. Meer nadruk op privacy- en governance-structuren.

    De rode draad is telkens dezelfde. Vertrouwen moet uitlegbaar worden.

    De stille spanning die dan ontstaat

    Wat de SOC-2 vraag vaak blootlegt, is geen gebrek aan goede bedoelingen, maar een gebrek aan impliciete structuur. Veel teams werken op basis van vakmanschap en gezond verstand. Dat functioneert uitstekend, tot het onvoldoende blijkt.

    Zolang alles goed gaat, voelt impliciete beheersing comfortabel. Iedereen weet wat er van hem verwacht wordt. Problemen worden opgelost. Klanten zijn tevreden.

    Maar zodra iemand van buiten meekijkt, ontstaan vragen. Niet omdat er iets mis is, maar omdat niemand precies kan aanwijzen hoe het geregeld is.

    Wie beslist bij twijfel. Waar keuzes worden vastgelegd. Hoe structureel gedrag aantoonbaar is.

    Die vragen ontstaan pas wanneer vertrouwen getest wordt.

    Waarom “we zijn daar te klein voor” geen antwoord meer is

    De gedachte dat dit soort vragen alleen relevant zijn voor grote organisaties, houdt steeds minder stand. Juist compacte teams zijn kwetsbaar voor impliciete afspraken.

    Rollen lopen door elkaar. Taken worden informeel opgepakt. Kennis zit in hoofden, niet in structuren. Dat is efficiënt, tot iemand wegvalt of tot een klant expliciet vraagt hoe iets geborgd is.

    De SOC-2-vraag dwingt niet tot bureaucratie. Ze dwingt tot explicitering. Tot het zichtbaar maken van wat er in de praktijk al gebeurt.

    Wat organisaties die hier ontspannen mee omgaan anders doen

    Organisaties die rustig reageren op dit soort vragen, hebben zelden alles dichtgetimmerd. Wat ze wel hebben, is overzicht.

    Ze weten wie waarvoor verantwoordelijk is. Welke taken terugkeren. Waar besluiten worden vastgelegd. Hoe incidenten worden opgevolgd.

    Niet omdat een norm dat vraagt, maar omdat het rust geeft. Intern én extern.

    Daarmee verschuift compliance van last naar bijproduct. Niet iets wat erbij komt, maar iets wat meebeweegt met hoe er gewerkt wordt.

    Tot slot

    Wanneer iemand naar SOC 2 vraagt, vraagt hij zelden om een rapport.

    Hij vraagt of je begrijpt waar zijn zorgen zitten. Of je weet wat je belooft. En of je kunt laten zien dat je dat ook waarmaakt.

    SOC 2 is dan geen einddoel, maar een spiegel. Geen technische exercitie. Geen juridische verplichting.

    Maar een vraag over hoe je georganiseerd bent.

    Verder lezen

  • Wat is SOC 2 (en waarom je ‘m niet haalt met een mapje Word-bestanden)

    Wat is SOC 2 (en waarom je ‘m niet haalt met een mapje Word-bestanden)

    “We hadden alles netjes in een mapje. Beleid, procedures, risicoanalyse – het zat er allemaal in. Maar toen de auditor vroeg: ‘Welk bewijs heb je dat dit écht wordt nageleefd?’, werd het stil.”

    Steeds meer organisaties in de IT en zakelijke dienstverlening krijgen ermee te maken: klanten vragen om een SOC 2-verklaring. Niet omdat ze daar zelf op zitten te wachten, maar omdat hún klanten, toezichthouders of investeerders het eisen. En dus moet je als leverancier kunnen aantonen dat je gegevensbescherming, beschikbaarheid en procesbeheersing écht op orde hebt.

    Dat klinkt overzichtelijk. Tot je beseft wat SOC 2 in de praktijk vraagt.

    Wat is SOC 2 precies?

    SOC 2 (Service Organization Control 2) is een Amerikaanse standard voor het beoordelen van hoe een organisatie omgaat met klantdata. Het rapport wordt opgesteld door een onafhankelijke auditor, op basis van jouw eigen processen en maatregelen. Die moeten aantoonbaar bijdragen aan het waarborgen van de zogeheten Trust Service Criteria:

    1. Beveiliging (Security) – zijn je systemen beschermd tegen ongeautoriseerde toegang?
    2. Beschikbaarheid (Availability) – is je dienst beschikbaar zoals afgesproken?
    3. Verwerkingsintegriteit (Processing Integrity) – worden gegevens correct en volledig verwerkt?
    4. Vertrouwelijkheid (Confidentiality) – blijven vertrouwelijke gegevens intern en beschermd?
    5. Privacy – hoe wordt omgegaan met persoonsgegevens van klanten?

    Het grote verschil met veel andere normen? SOC 2 schrijft niet exact voor wat je moet doen, maar vraagt om bewijs dat maatregelen daadwerkelijk werken in de praktijk. Het draait om betrouwbaarheid in de uitvoering.

    SOC 2 vs. ISO 27001: twee wegen naar vertrouwen

    Veel organisaties denken dat SOC 2 en ISO 27001 inwisselbaar zijn. Maar hoewel beide draaien om informatiebeveiliging, verschillen ze sterk in aanpak:

    • ISO 27001 is een internationale norm voor het opzetten van een Information Security Management System (ISMS). Het draait om het structureren van je beleid, processen, risicoanalyse en continue verbetering. Je voldoet aan een vast eisenkader, en krijgt een certificaat van een geaccrediteerde instantie.
    • SOC 2 is een auditrapport, geen certificaat. Er zijn geen verplichte maatregelen, maar je moet kunnen aantonen dat de maatregelen die je zelf hebt gekozen, ook daadwerkelijk worden uitgevoerd en gevolgd. Een SOC 2-audit kijkt terug: wat heb je gedaan, en wat kun je bewijzen?

    Kort samengevat:

    ISO 27001SOC 2
    VormCertificeringAssurance-rapport
    Norm of frameworkFormele normPrincipe-gebaseerd framework
    DoelSysteem opzetten en onderhoudenAantonen dat processen werken
    ReikwijdteInformatiebeveiliging in de breedte (inclusief privacy, beschikbaarheid en vertrouwelijkheid binnen ISMS)Klantdata en betrouwbaarheid volgens Trust Service Criteria
    ToetsingVoldoen aan vaste eisenWerking aantonen over tijd (bijv. 6-12 maanden)

    Het is geen kwestie van kiezen tussen SOC 2 of ISO 27001. Veel organisaties gebruiken ze juist samen: ISO voor structuur en SOC 2 om klantvertrouwen te versterken.

    Waarom je SOC 2 niet haalt met een mapje Word-bestanden

    Het is verleidelijk om te beginnen met een gedeelde map: een Word-bestand met het beleid, een Excel-sheet met risico’s, een PDF’je met je security controls. Maar zodra de auditor je vraagt:

    • “Wanneer is deze controle uitgevoerd?”
    • “Wie heeft dit beoordeeld?”
    • “Is er opvolging geweest na dit incident?”
    • “Wat was de laatste wijziging en door wie is die gedaan?”

    …dan blijkt dat een map vol documenten weinig waard is zonder context, logging en opvolging.

    SOC2 Type II-audits beoordelen de effectiviteit van je controles over een periode van 6 tot 12 maanden. Het gaat niet alleen om wat je opschrijft, maar of je kunt aantonen dat je het structureel doet. Iedere maand. Elke medewerker. Alle maatregelen. En dat vraagt meer dan alleen statische documenten.

    Praktijkvoorbeeld: de audit die nét niet lukte

    Een SaaS-bedrijf kreeg een grote klant uit de financiële sector in het vizier. Er was maar één voorwaarde: een SOC 2-rapport. In allerijl werd een intern team samengesteld, het beleid opgepoetst, en alles netjes gedocumenteerd. Excel voor risico’s, SharePoint voor processen, Word voor het beveiligingsbeleid. Het team had er vertrouwen in.

    Tot de auditor langskwam.

    De controles waren afgesproken, maar niet aantoonbaar uitgevoerd. Incidenten werden besproken in meetings, maar nergens vastgelegd. Rollen waren informeel verdeeld, maar nergens expliciet. De maatregelen leken prima – maar het bewijs ontbrak.

    Resultaat: geen SOC 2-rapport, geen deal, en opnieuw beginnen.

    Wat je wél nodig hebt

    Een succesvolle SOC 2-audit vraagt niet om perfectie, maar om aantoonbaarheid. Je moet laten zien dat je processen zijn ingebed in de dagelijkse praktijk. Dat betekent:

    • Duidelijke rollen en verantwoordelijkheden
      Wie is verantwoordelijk voor het beoordelen van toegangsrechten? Wie logt incidenten? Wie volgt ze op?
    • Terugkerende taken en logging
      Worden maandelijks back-ups gecontroleerd? Zijn security-updates tijdig uitgevoerd? Met bewijs?
    • Versiebeheer op beleid en maatregelen
      Wat is het actuele beleid? Wanneer is het gewijzigd? Door wie?
    • Incidentbeheer en verbeteracties
      Worden incidenten structureel geregistreerd? Zijn er trends zichtbaar Is er een evaluatie gedaan?
    • Audit-trail
      Kun je per maatregel zien wie iets heeft uitgevoerd, wanneer en wat de uitkomst was?

    CompliTrack is ontwikkeld met dat doel: een toegankelijke GRC-oplossing voor organisaties die serieus aan de slag willen met risico- en compliance beheer, zonder zware implementaties of langdurige consultancytrajecten.

    Met CompliTrack kun je:

    • Incidenten registreren en opvolgen
    • Terug taken inplannen en loggen
    • Risicoanalyse uitvoeren en koppelen aan maatregelen
    • Documentatie beheren
    • Interne audits plannen en opvolgen
    • Alles centraal vastleggen – met bewijslast

    Kortom: het juiste evenwicht tussen eenvoud en aantoonbaarheid.

    Tot slot: vertrouwen win je niet met een Excel-sheet

    Een SOC-2 audit is geen toneelstuk waarin je laat zien dat je iets hebt opgeschreven. Het is een evaluatie van hoe je organisatie werkelijk functioneert. Dag in en dag uit.

    Wil je SOC 2 halen zonder dat je organisatie verandert in een papieren compliance-machine? Ontdek hoe CompliTrack je helpt om wél aantoonbaar te zijn – en niet alleen compliant te lijken, maar het ook écht te zijn.

    Plan een vrijblijvende demo of neem contact op voor advies over hoe jij je auditproces concreet aanpakt.

  • Alles was op papier geregeld. Tot SOC 2 om bewijs vroeg.

    Alles was op papier geregeld. Tot SOC 2 om bewijs vroeg.

    Ze hadden er maanden aan gewerkt.

    Een informatiebeveiligingsbeleid. Een risicoregister. Procedures voor onboarding, back-ups, toegangsbeheer. Alles keurig uitgewerkt, besproken met het team en opgeslagen in een strak georganiseerde map op SharePoint.

    Toen de SOC 2-audit dichterbij kwam, dachten ze: we zijn er klaar voor. En eerlijk gezegd leek het ook zo.

    Tot de auditor niet vroeg wát ze hadden, maar hoe ze konden aantonen dat het ook wérkte.

    De eerste vragen waren nog overzichtelijk:

    “Wanneer is dit beleid voor het laatst geëvalueerd?”
    “Wie is verantwoordelijk voor deze beheersmaatregel?”
    “Hoe volgen jullie actiepunten op?”
    “Welke risico’s zijn herzien na de wijziging van april?”

    Het team wist het ongeveer. Maar ze konden het niet laten zíen. Er was geen log. Geen taakgeschiedenis. Geen centraal overzicht. Wat ze wél hadden: Word-bestanden, Excel-sheets en e-mails.

    Versiebeheer gebeurde op gevoel.
    Acties zaten in hoofden.
    En processen waren onzichtbaar – behalve op papier.

    Het moment waarop controle verandert in twijfel

    De documenten waren inhoudelijk prima. Daar lag het niet aan. Maar er ontbrak iets: structuur. Traceerbaarheid. Bewijs.

    Toen de auditor vroeg waar hij kon zien dat taken ook echt waren uitgevoerd, werd het ongemakkelijk.

    De verantwoordelijke medewerker was ziek.
    Verzonden e-mails? Misschien nog ergens.
    Evaluatie van het beleid? Besproken in het teamoverleg, maar nergens vastgelegd.

    Wat eerst voelde als controle, veranderde in twijfel. En die twijfel werd zichtbaar.

    In onze eerdere blog over risicoanalyse schreven we:
    “De risicoanalyse hoeft niet perfect te zijn. Maar hij moet leven in je organisatie” –> De risicoanalyse: een onmisbaar instrument voor elke ondernemer

    In een SOC 2-traject wordt dat pijnlijk duidelijk. Je krijgt niet de vraag: “Heb je het geregeld”, je krijgt de vraag: “Kun je aantonen dat het werkt?”.

    De fout die veel bedrijven maken

    Ze beginnen met beleid. Logisch – dat is tastbaar. Iets dat je kunt schrijven, opslaan, afvinken.

    Maar beleid zonder opvolging is façade, en SOC 2 kijkt dwars door façades heen.

    Je moet kunnen aantonen:

    • Wat de status is van je beheersmaatregelen
    • Welke taken zijn uitgevoerd, door wie, en wanneer
    • Hoe incidenten worden geregistreerd en opgevolgd
    • Wanneer je risico’s hebt herzien – en waarom

    Als dat overzicht ontbreekt, ontstaat auditstress. En soms: auditfalen.

    Wat CompliTrack anders doet

    CompliTrack is ontworpen voor dit soort situaties.
    Voor bedrijven die wél serieus werk willen maken van compliance, maar geen zwaar en log GRC-systeem nodig hebben.

    Met CompliTrack:

    • Koppel je beleid aan risico’s, processen en acties
    • Volg taken automatisch op – met eigenaarschap en herinneringen
    • Bewijs wie wat heeft gedaan – en wanneer
    • Houd je auditacties overzichtelijk en aantoonbaar
    • Voorkom dat auditvoorbereiding voelt als damage control

    Zo wordt compliance niet iets dat je bijhoudt, maar iets dat je organiseert.

    Zoals we eerder schreven
    “Je hoeft geen zware tool te kiezen. Maar je hebt wél een systeem nodig dat niet uit elkaar valt zodra iemand dóórvraagt.” –> Wat een lichtgewicht GRC-systeem wél moet kunnen doen voor het MKB

    Later deze week publiceren we een praktische blog:
    Wat is SOC 2 – en waarom je ‘m niet haalt met een mapje Word-bestanden.

    Sta je aan het begin van een SOC 2- of ISA3402-traject?

    Of wil je zeker weten dat je niet alleen op papier compliant bent?

    Met CompliTrack maak je beleid, risico’s en opvolging aantoonbaar. Zonder paniek. Zonder zoekwerk. Zonder twijfel.

    Vraag een demo aan – en ontdek hoe grip eruit ziet.