SOC 2 voor AI-systemen
SOC 2 trust services criteria toegepast op AI-systemen, AI-specifieke controls, auditoverwegingen en hoe red teaming SOC 2-compliance ondersteunt voor AI-gestuurde diensten.
SOC 2 (System and Organization Controls 2) is het dominante auditkader voor serviceorganisaties in de Verenigde Staten. Naarmate organisaties AI steeds vaker in hun dienstenaanbod inbedden, moeten SOC 2-audits zich ontwikkelen om AI-specifieke risico's te adresseren. Red teamers die de SOC 2-vereisten begrijpen, kunnen bevindingen leveren die direct het auditbewijs ondersteunen en klanten helpen hun SOC 2-rapporten te behouden.
Trust Services Criteria toegepast op AI
SOC 2 is gebouwd op vijf Trust Services Criteria (TSC). Elk heeft specifieke implicaties voor AI-systemen:
Security (Common Criteria)
De security-categorie is altijd opgenomen in SOC 2-rapporten en vormt de basis voor controls voor AI-systemen:
| Criterium | Traditionele toepassing | AI-specifieke uitbreiding |
|---|---|---|
| CC6.1 (Logische toegang) | Authenticatie en autorisatie van gebruikers | Toegangscontroles voor model-API's, authenticatie van inference-endpoints, toegangsbeperkingen op promptniveau |
| CC6.3 (Toegangsintrekking) | Deprovisioning van gebruikersaccounts | Intrekken van API-sleutels, verwijderen van modeltoegang, uitschakelen van fine-tuned modelvarianten |
| CC6.6 (Grensbescherming) | Netwerksegmentatie, firewalls | Modelisolatie, filtering van prompt-injectie, in-/uitvoer-grenscontroles |
| CC6.7 (Dataoverdracht) | Versleuteling tijdens transport | Beschermen van prompts en completions tijdens transport, beveiligen van model-naar-modelcommunicatie |
| CC6.8 (Schadelijke software) | Antivirus, endpointbescherming | Detectie van adversariële invoer, filtering van schadelijke prompts, verificatie van modelintegriteit |
| CC7.2 (Monitoring) | Monitoring van beveiligingsgebeurtenissen | Monitoren op adversariële aanvallen, ongebruikelijke querypatronen, pogingen tot data-extractie |
| CC7.3 (Anomaliedetectie) | Intrusion detection-systemen | Gedragsmatige anomaliedetectie voor AI, detectie van prompt-injectie, monitoring van output-drift |
Availability
| Criterium | Traditionele toepassing | AI-specifieke uitbreiding |
|---|---|---|
| A1.1 (Capaciteitsbeheer) | Serverschaling, bandbreedteplanning | GPU-capaciteitsbeheer, beheer van inference-wachtrijen, schaalbaarheid van model serving |
| A1.2 (Herstelprocedures) | Back-up en disaster recovery | Model-rollbackprocedures, herstel van trainings-checkpoints, fallback-paden voor inference |
Processing Integrity
Processing integrity is bijzonder relevant voor AI-systemen, omdat hun outputs direct van invloed zijn op zakelijke beslissingen:
| Criterium | Traditionele toepassing | AI-specifieke uitbreiding |
|---|---|---|
| PI1.1 (Nauwkeurige verwerking) | Datavalidatie, verificatie van berekeningen | Monitoring van modelnauwkeurigheid, detectie van hallucinaties, outputvalidatie |
| PI1.2 (Volledige verwerking) | Volledigheid van transacties | Waarborgen dat AI alle invoer verwerkt zonder stille fouten of afkapping |
| PI1.3 (Tijdige verwerking) | SLA-naleving | Monitoring van inference-latentie, timeout-afhandeling voor AI-operaties |
| PI1.4 (Geautoriseerde verwerking) | Goedkeuringsworkflows | Human-in-the-loop-vereisten voor AI-beslissingen met hoge inzet |
| PI1.5 (Foutafhandeling) | Verwerking van uitzonderingen | Gracieuze degradatie wanneer modellen falen, documentatie van fallback-gedrag |
Confidentiality
| Criterium | Traditionele toepassing | AI-specifieke uitbreiding |
|---|---|---|
| C1.1 (Identificatie van vertrouwelijke data) | Dataclassificatie | Classificatie van trainingsdata, classificatie van promptinhoud, bescherming van modelgewichten |
| C1.2 (Vernietiging van vertrouwelijke data) | Veilige verwijdering | Model unlearning, verwijdering van trainingsdata, opschonen van gespreksdata |
Privacy
| Criterium | Traditionele toepassing | AI-specifieke uitbreiding |
|---|---|---|
| P1-P8 (Privacycriteria) | PII-verwerking, toestemming, toegang | Privacy van AI-trainingsdata, verwerking van promptdata, risico's van modelmemorisatie, gebruikersdata bij fine-tuning |
AI-specifieke controldoelstellingen
Naast het koppelen van bestaande TSC aan AI moeten organisaties aanvullende AI-specifieke controls implementeren. Deze breiden het SOC 2-kader uit om risico's te adresseren die uniek zijn voor AI-systemen:
Controls voor modelgovernance
| Control-ID | Doelstelling | Beschrijving | Red Team-test |
|---|---|---|---|
| AI-GOV-01 | Modelinventaris | Een volledige inventaris bijhouden van alle AI-modellen in productie | Volledigheid verifiëren door ongedocumenteerde modellen te ontdekken |
| AI-GOV-02 | Beheer van de modellevenscyclus | Modellen volgen van ontwikkeling tot buitengebruikstelling | Pogen toegang te krijgen tot afgeschreven of staging-modellen |
| AI-GOV-03 | Wijzigingsbeheer voor modellen | Modelwijzigingen goedkeuren en documenteren vóór deployment | Testen of niet-goedgekeurde modelversies kunnen worden gedeployd |
| AI-GOV-04 | Risico van externe modellen | Risico's van externe AI-providers beoordelen en monitoren | Gedrag van externe modellen testen, SLA-naleving verifiëren |
Controls voor modelbeveiliging
| Control-ID | Doelstelling | Beschrijving | Red Team-test |
|---|---|---|---|
| AI-SEC-01 | Preventie van prompt-injectie | Ongeautoriseerde acties via promptmanipulatie voorkomen | Aanvalsscenario's voor prompt-injectie uitvoeren |
| AI-SEC-02 | Outputfiltering | Gevoelige data in modeloutputs voorkomen | Data-extractie pogen via diverse outputkanalen |
| AI-SEC-03 | Toegangscontrole voor modellen | Modelmogelijkheden beperken op basis van gebruikersautorisatie | Privilege-escalatie testen via promptmanipulatie |
| AI-SEC-04 | Adversariële robuustheid | Modelgedrag handhaven onder adversariële omstandigheden | Adversariële tests over diverse invoermodaliteiten |
Controls voor dataverwerking
| Control-ID | Doelstelling | Beschrijving | Red Team-test |
|---|---|---|---|
| AI-DATA-01 | Governance van trainingsdata | Beheersen welke data wordt gebruikt voor training en fine-tuning | Herkomst en autorisatie van trainingsdata verifiëren |
| AI-DATA-02 | Isolatie van promptdata | Cross-user datalekkage via prompts voorkomen | Testen op gesprekslekkage tussen sessies |
| AI-DATA-03 | Dataretentie voor AI | Retentieperioden voor AI-interactiedata definiëren en afdwingen | Verifiëren dat verlopen data daadwerkelijk wordt verwijderd |
| AI-DATA-04 | Data-integriteit van RAG | Waarborgen dat retrieval-augmented generation geautoriseerde data gebruikt | RAG-vergiftiging en ongeautoriseerde data-injectie pogen |
Auditoverwegingen
SOC 2 Type I vs Type II voor AI-systemen
| Dimensie | Type I | Type II |
|---|---|---|
| Scope | Opzet van controls op een specifiek moment | Opzet en operationele effectiviteit over een periode (doorgaans 6-12 maanden) |
| AI-relevantie | Nuttig voor initiële lanceringen van AI-systemen | Vereist om aanhoudende effectiviteit van AI-controls aan te tonen |
| Rol van red team | Momentopname-beoordeling van AI-controls | Periodieke beoordelingen gedurende de auditperiode |
| Benodigd bewijs | Control-documentatie en review van de opzet | Testresultaten, monitoringlogs, incidentregistraties over de periode |
Waar auditors naar zoeken in AI-systemen
Veelvoorkomende auditorvragen over AI-controls:
| Vraag | Wat ze beoordelen | Hoe red teaming helpt |
|---|---|---|
| "Hoe voorkom je prompt-injectie?" | CC6.6 grensbescherming voor AI | Aantonen of controls tegen prompt-injectie daadwerkelijk werken |
| "Hoe monitor je het gedrag van het AI-systeem?" | CC7.2, CC7.3 monitoring en anomaliedetectie | Laten zien of monitoring adversariële activiteit detecteert |
| "Hoe voorkom je datalekkage via AI?" | C1.1 vertrouwelijke data, P3 dataverzameling | Data-extractie testen via modeloutputs |
| "Hoe beheer je modelwijzigingen?" | CC8.1 wijzigingsbeheer | Verifiëren dat procedures voor modelwijzigingen worden gevolgd |
| "Hoe handel je AI-fouten af?" | PI1.5 foutafhandeling | Faalmodi testen en gracieuze degradatie verifiëren |
Bewijsverzameling voor auditors
Red team-opdrachten die SOC 2 ondersteunen, moeten bewijs opleveren dat is opgemaakt voor auditgebruik:
| Bewijstype | Inhoud | SOC 2-relevantie |
|---|---|---|
| Testplannen | Scope, methodologie, gebruikte tools, geteste controls | Toont een systematische beoordelingsaanpak aan |
| Testresultaten | Gedetailleerde bevindingen met stappen om te reproduceren | Bewijst operationele effectiviteit (of falen) van controls |
| Verificatie van remediatie | Resultaten van hertests na controlverbeteringen | Toont effectiviteit van corrigerende maatregelen aan |
| Data van continue monitoring | Geautomatiseerde testresultaten over de auditperiode | Ondersteunt operationele effectiviteit voor Type II |
| Uitzonderingslogs | Gedocumenteerde controlfalen en reacties | Toont bewustzijn en reactievermogen van het management aan |
Structuur van red team-opdrachten voor SOC 2
Afstemming vóór de opdracht
Voordat je een red team-opdracht uitvoert ter ondersteuning van SOC 2, stem je af met het auditteam:
Identificeer AI-systemen binnen scope
Werk samen met de klant om te bepalen welke AI-systemen binnen de SOC 2-scopegrens vallen. Alleen AI-systemen binnen de vertrouwensgrens van de serviceorganisatie hoeven te worden getest.
Koppel controls aan testactiviteiten
Bekijk de control-matrix van de klant en koppel AI-specifieke controls aan red team-testscenario's. Elke control moet minstens één bijbehorende test hebben.
Stem timing af met auditors
Plan voor Type II-rapporten de tests met tussenpozen gedurende de auditperiode in plaats van allemaal tegelijk. Dit levert bewijs van aanhoudende effectiviteit van controls.
Spreek het bewijsformaat af
Bevestig bij de CPA-firma welk bewijsformaat zij vereisen. Sommige auditors accepteren red team-rapporten rechtstreeks; anderen hebben bevindingen nodig die zijn opgemaakt in hun testwerkpapieren.
Testmethodologie per Trust Service-categorie
Security-tests (CC-criteria):
- Prompt-injectieaanvallen tegen alle AI-endpoints
- Testen van API-authenticatie en -autorisatie
- Pogingen tot data-extractie via modeloutputs
- Extractie en misbruik van system prompts
- Tests met adversariële invoer
Availability-tests (A-criteria):
- Model-denial-of-service via resource-uitputting
- Stresstesten van de inference-pipeline
- Verificatie van failover- en fallback-gedrag
- Validatie van de recovery time objective
Processing integrity-tests (PI-criteria):
- Meting van het hallucinatiepercentage onder adversariële omstandigheden
- Outputmanipulatie via zorgvuldig opgestelde invoer
- Verificatie dat controls voor menselijk toezicht correct functioneren
- Gedrag van foutafhandeling bij onverwachte invoer
Confidentiality-tests (C-criteria):
- Pogingen tot extractie van trainingsdata
- Testen van cross-tenant datalekkage
- Extractie van modelgewichten en -configuratie
- Verificatie van isolatie van gespreksgeschiedenis
Privacy-tests (P-criteria):
- PII-extractie uit modeloutputs
- Verificatie van toestemmingsmechanismen voor AI-dataverzameling
- Verificatie van dataretentie en -verwijdering
- Isolatie van gebruikersdata in multi-tenant-omgevingen
Veelvoorkomende bevindingen en remediatie
Bevindingen die SOC 2-rapporten beïnvloeden
| Bevinding | SOC 2-impact | Ernst voor auditors |
|---|---|---|
| Geslaagde prompt-injectie die controls omzeilt | CC6.6 control-falen | Hoog -- kan leiden tot een verklaring met beperking |
| Data-extractie via modeloutputs | C1.1, P3 control-falen | Hoog -- impact op vertrouwelijkheid en privacy |
| Geen monitoring op adversariële invoer | CC7.2, CC7.3 hiaat | Gemiddeld -- detectietekortkoming |
| Modelwijzigingen gedeployd zonder goedkeuring | CC8.1 control-falen | Gemiddeld -- hiaat in wijzigingsbeheer |
| Geen fallback-gedrag wanneer het model faalt | PI1.5, A1.2 hiaat | Gemiddeld -- processing integrity en availability |
| Ongedocumenteerde AI-modellen in productie | AI-GOV-01 hiaat | Laag tot gemiddeld -- volledigheid van de inventaris |
Remediatieprioriteiten
Onmiddellijke prioriteiten (oplossen voordat de auditperiode eindigt):
- Elk control-falen dat data-extractie of ongeautoriseerde toegang toestaat
- Ontbrekende monitoring op AI-specifieke aanvalspatronen
- Ongecontroleerde processen voor model-deployment
Verbeteringen op langere termijn:
- Geautomatiseerd adversarieel testen in CI/CD-pipelines
- Verbeterde dashboards voor gedragsmatige AI-monitoring
- Formele incidentresponsprocedures voor AI
- Regelmatige modelbeveiligingsreviews geïntegreerd in het wijzigingsbeheer
Integratie met andere frameworks
Organisaties onderhouden SOC 2 vaak naast andere compliance-frameworks. Red team-bevindingen moeten worden gekoppeld aan alle toepasselijke frameworks:
| SOC 2-criterium | ISO 42001-control | NIST AI RMF | EU AI Act |
|---|---|---|---|
| CC6.6 (Grensbescherming) | A.6.2.5 (Deployment) | MS-2.3 | Art. 15 (Cybersecurity) |
| CC7.2 (Monitoring) | A.6.2.6 (Monitoring) | MG-2.4 | Art. 9 (Risk management) |
| PI1.1 (Nauwkeurige verwerking) | A.6.2.4 (Verification) | MS-2.6 | Art. 15 (Accuracy) |
| C1.1 (Confidentiality) | A.7.4 (Data provenance) | MP-4.2 | Art. 10 (Data governance) |
| P3 (Collection) | A.10.2 (Fairness) | GV-6.1 | Art. 13 (Transparency) |
Door deze cross-koppeling kan een enkele red team-opdracht bevindingen opleveren die relevant zijn voor meerdere compliance-vereisten, waardoor het rendement op de investering wordt gemaximaliseerd voor klanten die complexe compliance-landschappen beheren.