SOC 2 voor cloud providers

SOC 2 voor cloudproviders is een onafhankelijk rapport dat bewijst dat je hosting-infrastructuur veilig, beschikbaar en vertrouwelijk is. Je laat een accountant je beveiliging toetsen aan de AICPA Trust Services Criteria . Klanten die op jouw servers draaien vragen dit rapport op voordat ze met je in zee gaan.

Je host infrastructuur voor anderen. Klanten draaien hun applicaties op jouw servers. SOC 2 is niet alleen handig, het is de industriestandaard. Hyperscalers (AWS, Azure, GCP) hebben het. Managed service providers hebben het. Jij ook.

Cloud providers worden vaak geaudit op meerdere Trust Services Criteria tegelijk. Zie ook de veelgebruikte controls voor concrete voorbeelden.

SOC 2 voor cloudproviders in het kort

Waarom SOC 2 essentieel is voor cloud en hosting

Eis van je klanten: Elke klant die op jouw infrastructuur draait moet zelf compliant zijn (GDPR, ISO 27001, SOC 2). Ze vragen jouw SOC 2 op als onderdeel van hun vendor risk management. Zonder SOC 2 kunnen ze je niet als leverancier accepteren.

Shared responsibility model: Jij bent verantwoordelijk voor de beveiliging van de cloud (fysiek, netwerk, hypervisor). De klant is verantwoordelijk voor de beveiliging in de cloud (hun apps, hun data). Je SOC 2 toont dat jouw deel op orde is.

Concurrentie: AWS, Azure en GCP hebben SOC 2. Kleinere cloud providers ook. Zonder SOC 2 kun je niet meedoen. “Waarom zouden we voor jullie kiezen in plaats van AWS?” Je antwoord moet minstens zijn: “We hebben dezelfde compliance.”

Cloud-specifieke SOC 2 controls

1. Fysieke beveiliging (kritiek voor eigen datacenter)

Als je eigen hardware hebt, is fysieke beveiliging een groot onderdeel.

Controls:

• Terreinbeveiliging: Hekken, poorten, bewakers
• Toegangscontrole: Badgesystemen, biometrie (vingerafdruk, iris)
• Bezoekersbeheer: Logboek, verplichte begeleiding, tijdelijke badges
• Cameratoezicht: 24/7 camera’s, opnames minimaal 90 dagen bewaard
• Klimaat en stroom: Brandblussysteem, koeling, noodstroom (UPS, generatoren)
• Asset tracking: Serverinventaris, procedures voor buitengebruikstelling

Wat de auditor vraagt:

• “Laat de toegangslogs van het datacenter zien. Wie kwam de laatste 6 maanden binnen?”
• “Hoe regel je bezoekerstoegang?”
• “Wat gebeurt er als een onbevoegde binnenkomt?”
• “Laat een steekproef van camerabeelden zien.”

Als je colocation gebruikt: Je huurt ruimte in het datacenter van een ander (Equinix, Digital Realty). Hun fysieke beveiliging is jouw control. Je moet:

• Het SOC 2 rapport van de leverancier hebben
• Eigen toegangscontroles binnen je cage of rack
• Bezoeklogs bijhouden
• De auditor het SOC 2 rapport van je leverancier kunnen tonen

Als je volledig in de cloud zit (AWS/Azure/GCP): Fysieke beveiliging is de verantwoordelijkheid van AWS, Azure of GCP. De auditor accepteert hun SOC 2 als bewijs. Jouw scope: logische toegang, niet fysieke toegang.

2. Hypervisor- en virtualisatiebeveiliging

Je draait klanten in VM’s of containers. Hoe isoleer je ze?

Controls:

• Hypervisor hardening: ESXi, KVM, Hyper-V up-to-date en gepatcht
• VM-isolatie: De VM van klant A kan die van klant B niet benaderen
• Resource-toewijzing: CPU- en geheugenlimieten per tenant (voorkomt noisy neighbor)
• Netwerksegmentatie: VLAN’s, VPC’s per klant
• Escape-preventie: Kwetsbaarheden in de hypervisor worden snel gepatcht

Wat de auditor vraagt:

• “Leg je virtualisatie-architectuur uit.”
• “Hoe voorkom je een VM-escape?”
• “Laat de netwerkisolatie zien. Kan VM A het netwerk van VM B bereiken?”
• “Stel dat er een kwetsbaarheid in de hypervisor zit, binnen welke termijn patch je die?”

Bewijs:

• Architectuurdiagram (hypervisor, netwerk)
• Logs van patchmanagement (hypervisor-updates)
• Configuratie van netwerksegmentatie
• Penetratietest: poging tot VM-escape (moet falen)

Best practice: Gebruik hardware-isolatie waar mogelijk (Intel VT-x, AMD-V). Gebruik namespaces en cgroups voor containers. Doe regelmatig security-audits van je hypervisor-config.

3. Netwerkbeveiliging en DDoS-bescherming

Je netwerk is publiek bereikbaar. DDoS-aanvallen zijn realiteit.

Controls:

• DDoS-mitigatie: Scrubbing centers, rate limiting, null routing
• Firewalls: Stateful firewalls, standaard alles dicht
• IDS/IPS: Detectie en preventie van inbraak
• Verkeersmonitoring: NetFlow, anomaliedetectie
• Bandbreedtebeheer: QoS, traffic shaping
• Peering: Meerdere upstream providers (redundantie)

Wat de auditor vraagt:

• “Wat is je DDoS-mitigatiestrategie?”
• “Laat een recente DDoS-aanval zien en hoe je die hebt aangepakt.”
• “Hoe bescherm je het verkeer van klanten?”
• “Welke monitoring heb je?”

Bewijs:

• Documentatie van DDoS-mitigatie
• Netwerkdiagrammen
• Incidentlogs (DDoS-aanvallen)
• Monitoring-dashboards

Focus op Availability: DDoS is een risico voor beschikbaarheid. De auditor checkt of je voorbereid bent. Je moet kunnen aantonen: “We hadden een DDoS-aanval, binnen X minuten gemitigeerd, de impact op klanten was Y.”

4. Data-isolatie tussen klanten

Je klanten delen dezelfde infrastructuur. Hoe voorkom je datalekken?

Controls:

• Opslag-isolatie: Aparte volumes, encryptiesleutels per tenant
• Database-isolatie: Aparte databases of sterke isolatie op schemaniveau
• Backup-isolatie: De backup van klant A is niet toegankelijk voor klant B
• Netwerk-isolatie: VPC’s, security groups, firewalls
• Metadata-scheiding: Zelfs metadata (logs, facturatie) is per tenant gescheiden

Wat de auditor vraagt:

• “Hoe zorg je dat klant A de data van klant B niet kan zien?”
• “Laat je opslagarchitectuur zien.”
• “Wat gebeurt er bij een misconfiguratie?”
• “Heb je geautomatiseerde checks op tenant-isolatie?”

Bewijs:

• Architectuurdiagrammen
• Code- en configreviews: tenant-filtering wordt afgedwongen
• Geautomatiseerde tests: pogingen tot cross-tenant toegang (moeten falen)
• Bevindingen uit penetratietests

5. Toegangsbeheer voor klanten

Klanten hebben toegang tot je portal, API of infrastructuur. Hoe beheer je dat?

Controls:

• MFA: Verplicht voor alle klantaccounts
• RBAC: Klanten kunnen rollen definiëren (admin, gebruiker, alleen-lezen)
• API-sleutels: Mogelijkheid tot rotatie, afgebakende rechten
• Toegangslogs: Alle acties van klanten worden gelogd
• Sessiebeheer: Time-outs, beveiligde tokens

Wat de auditor vraagt:

• “Laat het inlogproces voor klanten zien.”
• “Wordt MFA afgedwongen?” (ja)
• “Kunnen klanten elkaars data zien?” (nee)
• “Laat de API-authenticatie zien.”

Bewijs:

• Screenshots van de klantportal
• Configuratie van MFA-afdwinging
• API-documentatie (authenticatie-eisen)
• Toegangslogs

6. Incident response voor infrastructuur

Incidenten in cloud en hosting hebben bredere impact (meerdere klanten tegelijk).

Controls:

• Incidentclassificatie: Severity-niveaus (SEV1, SEV2, enzovoort)
• Escalatiematrix: Wie bel je bij welke severity
• Communicatie naar klanten: Transparantie tijdens incidenten (status page)
• Postmortems: Na elk groot incident leg je de oorzaak vast
• SLA-credits: Bij een geschonden SLA krijgt de klant compensatie

Wat de auditor vraagt:

• “Laat een recent infrastructuurincident zien.”
• “Hoe communiceerde je met klanten?”
• “Wat was de oorzaak en wat heb je gefixt?”
• “Laat het postmortem-document zien.”

Bewijs:

• Incidentlog (laatste 12 maanden)
• Voorbeeldincident plus postmortem
• Communicatie naar klanten (updates op de status page)
• Genomen maatregelen

Een status page is kritiek: Een publieke status page (StatusPage.io, Atlassian Statuspage) waar klanten realtime updates zien. De auditor verwacht dit voor Availability.

7. Capaciteitsplanning en schalen

Je moet vooruit plannen. Klantgroei, seizoenspieken.

Controls:

• Resource-monitoring: CPU, geheugen, schijf, bandbreedte per datacenter of regio
• Forecasting: Capaciteitsreviews per kwartaal, trendanalyse
• Schaalprocedures: Auto-scaling waar mogelijk, handmatig schalen gedocumenteerd
• Drempelwaarschuwingen: 80% capaciteit betekent uitbreiding plannen
• Doorlooptijden: Weet hoe lang het duurt om capaciteit toe te voegen (hardware bestellen, inrichten)

Wat de auditor vraagt:

• “Hoe plan je capaciteit?”
• “Laat een recente capaciteitsreview zien.”
• “Wat gebeurt er als je tegen je capaciteitslimiet aanloopt?”
• “Heb je ooit zonder capaciteit gezeten? Hoe heb je dat opgelost?”

Bewijs:

• Verslagen van capaciteitsreviews per kwartaal
• Grafieken van resourcegebruik (6-12 maanden)
• Schaalmomenten (toegevoegde capaciteit)
• Communicatie naar klanten (bij capaciteitsproblemen)

8. Dataretentie en veilig afvoeren van apparatuur

Servers en schijven worden buiten gebruik gesteld. Klantdata moet veilig gewist worden.

Controls:

• Beleid voor dataverwijdering: Klantdata wordt binnen X dagen na contracteinde verwijderd
• Schijven wissen: DOD 5220.22-M standaard of beter (minstens 3 overschrijvingen)
• Fysieke vernietiging: Schijven die niet te wissen zijn, worden vernietigd
• Certificaat van vernietiging: Voor klanten met regelgeving-eisen
• Afvoerlog: Houd buiten gebruik gestelde hardware bij

Wat de auditor vraagt:

• “Laat je proces voor buitengebruikstelling zien.”
• “Hoe wis je schijven?”
• “Laat een recente afvoerlog zien.”
• “Hoe ga je om met kapotte schijven?”

Bewijs:

• Procedure voor buitengebruikstelling
• Voorbeeld van een afvoerlog
• Certificaat van vernietiging (bij fysieke vernietiging)
• Contracten met leveranciers (bij uitbestede afvoer)

Controls die extra belangrijk zijn voor cloud

Backup en disaster recovery (heel kritiek)

Waarom extra kritiek: Je host data voor honderden tot duizenden klanten. Falende backups zijn een ramp.

Controls:

• Geautomatiseerde dagelijkse backups (per klant)
• Off-site opslag (andere regio of provider)
• Versleutelde backups (in rust en tijdens transport)
• Regelmatige restore-tests: Wekelijks (steekproef), maandelijks (volledige restore)
• Backup-monitoring: een melding als een backup mislukt
• Bewaartermijn: 30 dagen dagelijks, 12 maanden wekelijks

Wat de auditor checkt:

• “Laat de backup-logs van 6 maanden zien.”
• “Wanneer was de laatste restore-test?” (moet recent zijn)
• “Laat een geslaagde restore zien.” (demo of bewijs)
• “Wat gebeurt er als een backup mislukt?” (melding plus onderzoek)

Veelgemaakte fout: Backups draaien wel, maar worden nooit getest. Een klant vraagt een restore en die mislukt. De auditor hoort dit verhaal, en dat is een grote finding. Test je backups consequent.

SLA-monitoring (kritiek voor Availability)

Waarom extra kritiek: Je hebt waarschijnlijk een SLA van 99,9% of 99,95%. De auditor gaat dit checken.

Controls:

• Externe uptime-monitoring (niet alleen intern)
• SLA-rapportage: maandelijkse rapporten aan klanten
• Downtime-registratie: alle incidenten gelogd
• Oorzaakanalyse: bij elke storing
• SLA-credits: geautomatiseerd of handmatig proces

Wat de auditor checkt:

• “Laat 12 maanden uptime-data zien.”
• “Haalde je je SLA?” (zo nee: waarom, en wat deed je?)
• “Laat de SLA-rapporten aan klanten zien.”
• “Hoe bereken je uptime?” (methodiek)

Beschikbaarheidsdoelen:

Is je SLA 99,9% en had je 2 uur downtime in één maand, dan heb je hem geschonden. De auditor wil weten: is de klant gecompenseerd, en is de oorzaak verholpen?

Change management (extra streng)

Waarom extra kritiek: Changes raken alle klanten. Een slechte change betekent een grote storing.

Controls:

• Onderhoudsvensters: minstens 72 uur vooraf aangekondigd
• Goedkeuring: door een senior engineer plus een manager
• Testen: een staging-omgeving die productie nabootst
• Terugrolplan: altijd een rollback klaar hebben
• Gefaseerde uitrol: canary deployments, blue-green
• Monitoring tijdens en na de change: extra waakzaam
• Noodprocedure: voor kritieke security-patches

Wat de auditor checkt:

• Steekproef van 20 changes: goedkeuring, testen, terugrolplan?
• Mislukte change: hoe rolde je terug, en wat was de impact op klanten?
• Noodchange: was het echt een noodgeval, en is het vastgelegd?

Best practice: Immutable infrastructure (containers, Kubernetes). Changes zijn nieuwe deployments, geen aanpassingen ter plekke. Terugrollen betekent terug naar de oude deployment. Veel veiliger.

Scope-overwegingen voor cloud providers

Wat hoort in scope?

Moet erin:

• Hosting-infrastructuur (servers, netwerk, opslag)
• Klantportals (facturatie, beheerinterface)
• API’s voor klantbeheer
• Supportsystemen (ticketing, klantcommunicatie)

Overweeg op te nemen:

• Monitoring- en loggingsystemen
• Backup-infrastructuur
• Securitytools (SIEM, IDS/IPS)

Kun je uitsluiten (maar voorzichtig):

• Interne HR-systemen (tenzij HR toegang heeft tot productie)
• Marketingwebsite (los van het klantplatform)
• Ontwikkel- en testomgevingen (als die volledig geïsoleerd zijn)

Trust Services Criteria voor cloud

Gangbare keuze: Security, Availability en Confidentiality

Security: De basis, je bent beschermd tegen hackers Availability: Je kernwaarde is uptime Confidentiality: Klantdata moet vertrouwelijk blijven

Overweeg ook: Processing Integrity: Als je facturatie of metering voor klanten doet Privacy: Als je persoonsgegevens verzamelt verder dan basale contactgegevens

Heraudit en continuous compliance

Jaarlijks vernieuwen: Cloud- en hostingomgevingen veranderen vaak. Nieuwe datacenters, nieuwe diensten, overnames. De heraudit moet dit weerspiegelen.

Scope bijwerken: Lanceer je een nieuwe dienst (bijvoorbeeld een managed database), moet die dan de volgende audit in scope? Ja, als klanten er data in opslaan.

Continue monitoring: Tools zoals Drata en Vanta helpen, maar voor infrastructuur is het complexer. Je hebt waarschijnlijk eigen scripts nodig om compliance te monitoren.

SOC 2 kosten voor cloud providers

Hoger dan bij SaaS: Cloud providers hebben vaak hogere auditkosten door:

• Fysieke beveiliging die geauditeerd moet worden (bezoeken aan datacenters)
• Meer systemen in scope
• Complexere infrastructuur
• Meerdere locaties (bij meerdere datacenters)

Indicatie kosten (Type II):

• Kleine cloud provider (1 datacenter, onder 50 medewerkers): €50k-€80k
• Middelgroot (2-3 datacenters, 50-200 medewerkers): €80k-€150k
• Groot (meerdere regio’s, 200+ medewerkers): €150k-€300k+

Tel consultancy, tooling en interne tijd erbij op: totaal €100k-€400k+ in het eerste jaar. Zie de kosten en tijdlijn voor het volledige overzicht.

Checklist voor cloud providers

Voordat je aan SOC 2 begint:

Fysiek:

• Toegangscontrole datacenter (badges, bezoekers, camera’s)
• Klimaat- en stroomvoorzieningen (brand, koeling, noodstroom)
• Asset tracking en buitengebruikstelling

Infrastructuur:

• Hypervisor gehard en gepatcht
• Netwerksegmentatie per tenant
• DDoS-mitigatie
• Firewall-regels gedocumenteerd
• IDS/IPS uitgerold

Data:

• Tenant-isolatie getest (penetratietests)
• Encryptie in rust en tijdens transport
• Backups geautomatiseerd en getest (restore-tests)
• Procedures voor dataverwijdering

Operatie:

• Change management-proces
• Incident response-plan en testen daarvan
• SLA-monitoring en rapportage
• Capaciteitsplanning per kwartaal
• Status page voor transparantie naar klanten

Leveranciers:

• Upstream providers (ISP’s, stroom, colocation) hebben SOC 2
• Hardwareleveranciers gedocumenteerd
• Afvoerleverancier (indien gebruikt)

Heb je 80%+ aangevinkt, dan ben je klaar.

Meer informatie

• Stappenplan – De 12 stappen naar SOC 2
• Kosten en tijdlijn – Wat kost het
• Trust Services Criteria – De 5 pijlers
• Controls – Concrete voorbeelden
• Voor SaaS – SaaS-specific tips