In het kort
- Een subservice-organisatie is een externe partij wiens diensten deel uitmaken van jouw systeem, zoals een cloudplatform.
- Bij carve-out valt zij buiten de scope van je rapport, bij inclusive erbinnen.
- Grote cloudplatformen leveren eigen SOC-rapporten, met een eigen scope en periode.
- Ook bij carve-out blijf je verantwoordelijk voor het toezicht op de leverancier.
Kort antwoord
Draait je dienst op AWS of Azure, dan is die cloudleverancier in de regel een subservice-organisatie in je SOC 2. Je kiest dan tussen carve-out en inclusive. Hoe je het rapport van zo'n leverancier leest, staat op de pagina over het lezen van een SOC 2-rapport. Cloudplatformen worden in de praktijk vaak als carve-out behandeld; zij laten zelf SOC-rapporten opstellen die je kunt gebruiken. Je eigen verantwoordelijkheid blijft: je beoordeelt hun rapport en beheerst de afhankelijkheid. Volgens de NOREA-handreiking ligt de keuze tussen opname (inclusive) en uitsluiting (carve-out) bij de serviceorganisatie, en toetst de auditor de argumenten van het management.
Wat is een subservice-organisatie
In een SOC 2-rapport is de serviceorganisatie de organisatie die de dienst levert en het rapport laat opstellen. Een subservice-organisatie (in het Engels: subservice organization) is een externe partij die een deel van die dienst levert. Bepalend is of haar controls moeten meewerken om jouw toezeggingen na te komen, en niet de omvang van het contract.
Stel dat je een SaaS-dienst bouwt die op een cloudplatform draait. Dan is dat platform meestal een subservice-organisatie. Een leverancier is echter niet automatisch een subservice-organisatie. Neemt de serviceorganisatie zelf de verantwoordelijkheid voor de risico's en de nodige controls, dan hoeft er volgens de NOREA-handreiking geen aanleiding te zijn om haar zo te kwalificeren. Als voorbeelden noemt de handreiking installatiebedrijven en verhuurders van datacenterlocaties.
De AICPA, die de standaarden voor SOC-opdrachten vaststelt, ziet SOC-rapporten als hulpmiddel om de risico's van uitbesteding te beoordelen.
Carve-out of inclusive
Bij de carve-out-methode (uitgesloten) sluit je de leverancier uit van de scope van je rapport. Bij de inclusive-methode (inbegrepen) neem je haar op, zodat de auditor ook haar controls onderzoekt. Scope is de afbakening van wat de auditor onderzoekt.
Bij carve-out staat de leverancier in je systeembeschrijving, met naam, dienst en de uitgesloten controls. Die controls worden beschreven, maar niet getest, dus het oordeel gaat alleen over jouw eigen controls. Bij inclusive maakt de leverancier haar controls herkenbaar, verklaart ze schriftelijk en geeft ze de auditor toegang.
In de praktijk wordt carve-out vaak gekozen en komt inclusive volgens praktijkbronnen zelden als standaard voor, mede omdat de leverancier moet meewerken. De keuze is volgens de NOREA-handreiking aan de serviceorganisatie. Kies je voor carve-out, dan moet het management dat motiveren en komt die motivatie in het rapport. Per leverancier kun je een andere keuze maken.
| Aspect | Carve-out | Inclusive |
|---|---|---|
| Leverancier binnen de scope van je rapport | Nee | Ja |
| Controls van de leverancier getest door de auditor | Nee, alleen beschreven | Ja |
| Medewerking van de leverancier | Niet nodig voor het onderzoek, wel voor je eigen monitoring | Nodig: schriftelijke verklaring, toegang en medeverantwoordelijkheid voor de beschrijving |
| Wat jij zelf moet doen | Het rapport van de leverancier beoordelen en de afhankelijkheid beheersen | Samenwerking en documentatie met de leverancier regelen |
| Waar de auditor op let | Of jouw toezicht op de leverancier deugdelijk is | Of de controls van de leverancier werken |
CSOC's en CUEC's uit elkaar houden
Bij carve-out noem je de controls waarop je rekent bij de leverancier: de complementary subservice organization controls (CSOC's). Het zijn controls die de leverancier moet hebben lopen om jouw doelstellingen te halen. Volgens de NOREA-handreiking moet de systeembeschrijving bij een uitgesloten subservice-organisatie onder meer de aard van de diensten noemen, aangeven waar controls (mede) bij de leverancier liggen en de controls beschrijven die daar nodig zijn om aan de criteria te voldoen. De subservice-organisatie en de gekozen methode moeten ook in de verklaring van het management en in het oordeel van de auditor staan.
De complementary user entity controls (CUEC's) zijn controls die de afnemer zelf moet uitvoeren. De term kent twee richtingen: in je eigen rapport gaat het om je klanten, in het rapport van je leverancier om jou. Dat tweede type vertaal je naar je eigen controls.
Let op: carve-out is geen vrijwaring. Het laat de afhankelijkheid zien, maar je verantwoordelijkheid verdwijnt niet.
Cloudplatformen in je SOC 2
Grote cloudplatformen laten zelf SOC-rapporten opstellen. Bij AWS vraag je die aan via AWS Artifact in de console. Voor SOC 1- en SOC 2-rapporten is een geheimhoudingsverklaring (NDA) nodig, en het SOC 3-rapport is publiek. Bij Azure vind je de rapporten in het Service Trust Portal van Microsoft, onder SOC-rapporten.
Controleer de scope. Bij AWS vallen alleen diensten die al in scope zijn onder de rapporten, en de lijst staat op een aparte pagina. Bij Azure staat de lijst in het rapport zelf of op de pagina over cloudservices in de audit scope. Kijk voor elke dienst die jij gebruikt of die erin staat.
De periode telt ook mee. Cloudplatformen publiceren hun rapporten op vaste momenten, vaak meerdere keren per jaar, en elk rapport beslaat een eigen periode. Lees die periode in het rapport zelf en vergelijk haar met jouw auditperiode.
Je auditperiode sluit zelden precies aan op die van de leverancier. Het gat overbruggen leveranciers vaak met een bridge letter: een verklaring van hun management over de tijd die het rapport niet dekt. Vraag bij je leverancier na hoe je zo'n brief krijgt. Er zit geen auditoroordeel bij, dus het is zwakker bewijs dan een rapport.
Shared responsibility. De gedeelde verantwoordelijkheid (shared responsibility) houdt in dat de cloudleverancier de infrastructuur beveiligt en jij wat je er zelf op bouwt en configureert. De verdeling hangt af van het servicemodel. Bij IaaS beheer jij de machines, het besturingssysteem en de applicaties. Bij PaaS zet jij alleen applicaties neer, en bij SaaS gebruik je een kant-en-klare applicatie. Je data en identiteiten blijven altijd bij jou.
Bij AWS geldt dezelfde logica: bij een virtuele machine is de klant verantwoordelijk voor het besturingssysteem, de patches en de firewallconfiguratie.
Let op: deze verdeling is illustratief en geen juridisch oordeel. Wat contractueel geldt, staat in je overeenkomst. Dit is algemene informatie, met peildatum oktober 2026.
Wat de auditor van jou verwacht
Bij carve-out test de auditor de leverancier niet, maar hij beoordeelt wel of jouw toezicht deugdelijk is. Die monitoring is jouw verantwoordelijkheid, welke methode je ook kiest, en hoort in je systeembeschrijving. Hoe zo'n audit verloopt, staat op de pagina over het SOC 2-auditproces.
Volgens de NOREA-handreiking moeten er monitoringsmaatregelen worden ingericht voor de controls die bij subservice-organisaties liggen. Het beoordelen van het SOC-rapport van de leverancier is in de praktijk de gebruikelijke manier om dat te doen. Ook periodiek overleg of eigen testen kunnen deel uitmaken van je toezicht.
Een auditor wil zien dat je het rapport serieus hebt beoordeeld. Loop daarvoor in elk geval vier punten na:
- Scope: dekt het rapport jouw diensten en de bijbehorende controls?
- Periode: sluit het aan op jouw auditperiode, en hoe is het gat overbrugd?
- Afwijkingen (exceptions): zijn ze relevant voor wat jij gebruikt? Zo ja, dan heb je mogelijk een compenserende control nodig. Bij Azure staan de reacties van het management aan het eind.
- Mapping: elke CSOC die je rekent op de leverancier moet als werkende control in hun rapport staan, en elke CUEC van de leverancier moet aansluiten op een control van jou. Gaten worden vaak laat ontdekt.
Dit valt in SOC 2-termen doorgaans onder criterium CC9.2, over risico's van leveranciers en zakelijke partners. Zie ook de Trust Services Criteria.
Overleg vroeg met je auditor. De keuze voor carve-out of inclusive hoort bij de planning, niet in het veldwerk. Voor je een leverancier kiest, doe je due diligence: een voorafgaand onderzoek naar hun beveiliging en rapporten.
Beoordeel het rapport van elke belangrijke leverancier minstens jaarlijks, en opnieuw zodra er een nieuw rapport verschijnt. Leg vast wanneer dat gebeurde en wat de conclusie was. Welk bewijs (evidence) je per criterium verzamelt, staat in de checklist over bewijs per criterium.
Afvinklijst
Leg per subservice-organisatie vast:
- De naam van de leverancier en de dienst die zij levert.
- Welke van je systemen en diensten van haar afhankelijk zijn.
- De gekozen methode, met onderbouwing en datum.
- Het type rapport (zie ook Type 1 versus Type 2), de periode en de datum van het rapport.
- Of de diensten die je gebruikt in de scope van het rapport staan.
- Hoe het gat tussen de rapportperiode en jouw auditperiode is afgedekt.
- De afwijkingen, je beoordeling van hun relevantie en eventuele compenserende controls.
- De CSOC's die je op de leverancier rekent, en waar die in hun rapport terugkomen.
- De CUEC's van de leverancier die jij uitvoert, en welke van je controls die afdekken.
- Wie het rapport heeft beoordeeld, wanneer, en waar het bewijs staat.
- Wanneer je de leverancier opnieuw beoordeelt.
Veelgemaakte fouten
- Je denkt dat het rapport van de leverancier jouw controls dekt. Het dekt hun controls. Jouw configuratie, toegang en data blijven van jou.
- Je legt het rapport weg zonder het te lezen. Scope, periode en afwijkingen moeten bij jouw dienst passen.
- Je slaat het gat tussen twee periodes over. Stel dat jouw periode eindigt op 30 juni en het rapport van de leverancier op 31 maart. Dan zit er een gat van ongeveer drie maanden dat je moet kunnen verantwoorden.
- Je verwart CSOC's en CUEC's. CSOC's liggen bij de leverancier, CUEC's bij de partij die de controls moet uitvoeren.
- Je ziet de carve-out als uitweg. Het toont de afhankelijkheid, maar het neemt de monitoring niet over.
- Je controleert de mapping pas bij de audit. Gaten die dan opduiken, zijn lastig nog op te lossen.
Veelgestelde vragen
Moet ik altijd carve-out kiezen voor een cloudplatform?
Nee. Carve-out is in de praktijk de meest voorkomende aanpak, maar het is een keuze die bij de planning hoort en per leverancier wordt gemaakt. Bespreek die keuze vroeg met je auditor, want die beoordeelt of de keuze past bij je systeem en je toezeggingen.
Is het SOC-rapport van AWS of Azure genoeg om de leverancier af te vinken?
Niet vanzelf. Je moet nagaan of de diensten die je gebruikt in scope zijn, of de periode aansluit op jouw auditperiode en welke afwijkingen erin staan. Het toezicht op de leverancier blijft daarnaast jouw verantwoordelijkheid.
Wat is een bridge letter, en is die voldoende?
Een bridge letter is een verklaring van het management van de leverancier die het gat tussen twee rapportperiodes overbrugt. Omdat er geen auditoroordeel bij zit, is het zwakker bewijs. Bij een te lang gat moet je zelf aanvullende controles uitvoeren.
Wat doe ik als de leverancier geen SOC-rapport heeft?
Dan kun je andere vormen van monitoring gebruiken, zoals de output van de leverancier controleren, gesprekken voeren, sitebezoeken afleggen of controles laten testen door je eigen interne audit. Leg vast waarom je voor die aanpak kiest en welk restrisico overblijft.
Bronnen
- AWS: SOC-rapporten, veelgestelde vragen: de SOC-typen, de verkrijging via AWS Artifact, de NDA-eis, de rapportperiodes en de bridge letter.
- AWS Artifact: wat het portaal is en welke rapporten je er kunt downloaden.
- AWS: shared responsibility model: de verdeling van verantwoordelijkheden tussen AWS en de klant.
- Microsoft Learn: SOC 2 Type 2 voor Azure: de rapportperiode, publicatie, bridge letters en waar je het rapport vindt.
- Microsoft Learn: shared responsibility in de cloud: de verdeling per servicemodel (IaaS, PaaS, SaaS).
- NOREA, Handreiking voor SOC 2 en SOC 3 op basis van ISAE 3000 (december 2021): de opname- en uitsluitingsmethode, wie de keuze maakt, wat de systeembeschrijving moet bevatten en wanneer een leverancier een subservice-organisatie is.
- CompassITC: subservice organizations, carve-out versus inclusive: praktijkuitleg over beide methoden en over CSOC's en CUEC's.
- AICPA: SOC-diensten: het doel van SOC-rapporten en de rol van de AICPA bij de standaarden.