Criteria · Bewijs · Prijs

Kosten SOC 2-penetratietest

SOC 2 bevat geen control die zegt "voer een penetratietest uit". Auditors verwachten er toch een, en de meeste readinessbureaus staan erop. Begrijpen waarom verklaart wat de test moet opleveren, en daarmee wat u werkelijk moet kopen.

Waarom een raamwerk dat testen nooit noemt het toch vereist

SOC 2 is gebouwd op de Trust Services Criteria, geschreven als uitkomsten en niet als een checklist van activiteiten. Er bestaat geen control genaamd "penetratietesten". Dat verleidt mensen tot een van twee fouten: aannemen dat er geen test nodig is, of een grote kopen omdat een readinessleverancier dat zei.

Het bruikbare kader is dat een penetratietest bewijs is en geen eis. Het is voor de meeste organisaties de meest praktische manier om twee dingen aan te tonen:

  • CC4.1 - dat u evaluaties uitvoert om vast te stellen of uw controls daadwerkelijk aanwezig zijn en functioneren. Een onafhankelijke test is een directe, gedateerde, extern geproduceerde evaluatie, precies waar dit criterium naar zoekt.
  • CC7.1 - dat u kwetsbaarheden en ongeautoriseerde configuratiewijzigingen detecteert. Scanning dekt daar doorlopend een deel van; een test dekt het deel dat scanning niet bereikt.

Omdat het een bewijsvraag is en geen compliancevinkje, telt het oordeel van uw auditor. Vraag specifiek en schriftelijk wat hij zal accepteren voordat u iets scopet. Auditors verschillen, en dat verschil is soms duizenden dollars aan scope waard.

Hoe het bewijs eruit moet zien

Een rapport alleen is de meest voorkomende manier waarop deze control toch een bevinding krijgt. De volledige bewijsketen heeft vier delen, en de gaten zitten vrijwel altijd in de laatste twee.

  • Scope. De geteste scope moet herkenbaar het systeem zijn dat in uw SOC 2-rapport wordt beschreven. Beschrijft uw systeembeschrijving een multi-tenant SaaS-platform en dekte de test een ongeauthenticeerde marketingsite, dan valt de discrepantie meteen op.
  • Bevindingen. Geclassificeerd naar ernst, met onderbouwing in plaats van een onverklaarde kleur, en met reproductiestappen.
  • Remediatie. Gedocumenteerd, met data, en met een vastgelegd besluit voor alles wat wordt geaccepteerd in plaats van opgelost. Risicoacceptatie mag; stilte niet.
  • Verificatie. Bewijs dat oplossingen zijn hertest en bevestigd. Dit deel ontbreekt het vaakst, en het is het deel dat een rapport verandert in bewijs dat een control werkt.

Een attestatiebrief die vermeldt wat er is getest, wanneer, door wie en met welk resultaat is wat dit voor de auditor samenbindt, en het is wat uw klanten later zullen vragen. Hij hoort onderdeel van de opdracht te zijn en geen aparte aankoop.

Timing ten opzichte van uw observatievenster

Voor Type I, dat de opzet op een bepaald moment beoordeelt, volstaan meestal een recente test en een geloofwaardig remediatieplan. Voor Type II, dat de operationele werking over een periode van doorgaans drie tot twaalf maanden beoordeelt, moeten de test, de remediatie en de hertest alle binnen het venster vallen. Een test drie weken voor sluiting van het venster boeken laat geen ruimte voor de herstel-en-hertestcyclus, en dat is de meest voorkomende planningsfout.

Terugrekenend: drie tot vijf werkdagen testen voor een kleine applicatie, één tot drie weken voor uw engineers om het belangrijkste op te lossen, en een paar dagen voor de hertest. Een maand binnen het venster is comfortabel. Een week niet.

Scopen voor SOC 2 zonder te veel te kopen

De scope hoort het systeem uit uw systeembeschrijving te zijn, wat voor de meeste SaaS-bedrijven het product is en de infrastructuur waarop het draait. In de praktijk betekent dat de geauthenticeerde applicatie met elke gebruikersrol, de grens tussen klanttenants, de API en de cloudomgeving die het host.

Wat vaak binnen SOC 2-scope wordt verkocht en er zelden thuishoort: uw laptopvloot, als die buiten de systeembeschrijving valt; een volledige Active Directory-beoordeling, als u geen bedrijfsdomein hebt; en een red-teamopdracht, die een heel andere vraag beantwoordt dan CC4.1 stelt. Heeft een readinessleverancier u dit allemaal geoffreerd, vraag dan welk criterium elke post aantoont.

Wat het kost

SOC 2 verandert de testkosten niet, alleen de documentatie die u eruit nodig hebt. Voor een typisch SaaS-product begint een applicatiescope bij $500 en dekt die het geauthenticeerde product, de rollen, de tenantisolatie en de API. Zodra cloudinfrastructuur of een bedrijfsnetwerk werkelijk binnen de systeembeschrijving valt, wordt dat een infrastructuurscope vanaf $1.500.

Ondersteuning bij remediatie, de hertest en de attestatiebrief zijn inbegrepen in plaats van apart gefactureerd, wat hier zwaarder weegt dan bij de meeste opdrachten, omdat dat precies de artefacten zijn waar de auditor om zal vragen. De servicepagina SOC 2-penetratietest behandelt het testen zelf dieper, kosten van een penetratietest legt het algemene model uit, en het voorbeeldrapport toont de vorm die een auditor ontvangt.

Valt u ook onder PCI DSS, dan kunnen beide vaak één opdracht delen, al verschillen de bewijseisen. Zie kosten PCI DSS-penetratietest, of compliancegedreven testen voor hoe overlappende raamwerken worden afgehandeld.

Vragen over SOC 2-testen

Niet bij naam. De Trust Services Criteria zijn bewust geschreven als uitkomsten en niet als voorgeschreven activiteiten, en in geen enkel criterium staan de woorden "penetratietest". In de praktijk is een test de normale manier om CC4.1 aan te tonen, dat gaat over evaluaties of controls functioneren, en het ondersteunt CC7.1 over het detecteren van kwetsbaarheden en configuratiewijzigingen. Uw auditor bepaalt wat aan de criteria voldoet, dus het definitieve antwoord komt daarvandaan. Vraag het vroeg, want het antwoord bepaalt uw scope en uw planning.
Het verandert vooral de timing. Type I onderzoekt of controls op een bepaald moment passend zijn opgezet, dus een recente test en een remediatieplan volstaan meestal. Type II onderzoekt de operationele werking over een periode van doorgaans drie tot twaalf maanden, dus de auditor wil de test, de remediatie en de hertest allemaal binnen het observatievenster zien. Een test te laat in een Type II-venster plannen is een veelgemaakte en dure fout.
Meestal vier dingen: een gedefinieerde scope die het systeem uit uw beschrijving aannemelijk dekt, bevindingen met ernst en onderbouwing, gedocumenteerde remediatie met data, en bewijs dat de oplossingen zijn geverifieerd. Een attestatiebrief die vermeldt wat wanneer is getest bindt het geheel samen. Een rapport alleen, zonder remediatiespoor, is de meest voorkomende reden dat deze control een bevinding krijgt.
Het raamwerk verandert de onderliggende testkosten niet, alleen het bewijs dat u ervan nodig hebt. Voor een typisch SaaS-product betekent dat een applicatiescope vanaf $500, of vanaf $1.500 zodra cloudinfrastructuur of een bedrijfsnetwerk werkelijk in scope valt. Bureaus die een specifiek "SOC 2-pentest"-product verkopen, verkopen meestal dezelfde test met de documentatie anders verpakt.
Jaarlijks testen is de gangbare basislijn die auditors accepteren, met een extra test na een significante architectuurwijziging. Omdat Type II naar een periode kijkt en niet naar een datum, is de praktische eis dat er binnen elk observatievenster bewijs van testen en remediatie bestaat, niet dat een test op een bepaalde datum plaatsvindt.

Een test scopen voor een SOC 2-venster?

Breng de eis van uw auditor en uw observatievenster mee en ik scope terug vanaf de datum.

Contact