Ingenieurs die voor het eerst met SOC 2 te maken krijgen, stellen het zich vaak voor als een enorme code-audit. Meestal is dat niet het geval. SOC 2 is een verklaring op basis van de Trust Services Criteria, en het grootste deel van die criteria gaat over beleid, processen en bewijs dat controles gedurende een bepaalde periode zijn uitgevoerd. Slechts een deel wordt bepaald door wat je code doet, en als je weet welk deel dat is, wordt het hele proces een stuk minder mysterieus.
De criteria die de code raken
De criteria die betrekking hebben op code, bevinden zich in de CC6-familie voor logische toegang: CC6.1 (beperken van toegang tot wat een rol nodig heeft), CC6.6 (bescherming tegen bedreigingen van buiten de systeemgrens), CC6.7 (bescherming van gegevens tijdens transport en verplaatsing), plus CC7.2 (monitoring) en CC8.1 (wijzigingsbeheer). Als je kunt redeneren over wie wat kan bereiken, hoe gegevens tijdens transport worden beschermd en wat wordt gelogd, dan redeneer je over het grootste deel van de codegerichte aspecten van SOC 2.
Opvallend is dat veel van wat in de engineering als 'SOC 2-achtig' aanvoelt (bijvoorbeeld het bestaan van code reviews, goedkeuringen van wijzigingen, toegangsonderzoeken) bewijs is dat een proces is uitgevoerd, verzameld buiten de code. De code zelf heeft voornamelijk betrekking op de CC6-familie.
De uitzonderingen die bevindingen worden
Een auditor neemt steekproeven van deze controles over een bepaalde periode en schrijft een oordeel. Een enkele pull request die een IAM-rol uitbreidt naar een wildcard of de TLS-minimumversie verlaagt, kan een uitzondering in die periode veroorzaken: de controle heeft mogelijk niet zoals beschreven gewerkt voor die wijziging. Als dit in de PR wordt opgemerkt, is het een eenregelige oplossing. Als het tijdens de audit wordt ontdekt, is het een herstelactie met een papieren spoor.
Die asymmetrie is het hele argument om de CC6-aspecten bij de diff te controleren in plaats van uitzonderingen maanden later te ontdekken.