SOC 2 voor Cloud Providers

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

Waarom SOC 2 essentieel is voor cloud/hosting

Customer requirement: Elke klant die op jouw infrastructure draait moet hun eigen compliance halen (GDPR, ISO 27001, SOC 2, etc.). Ze vragen jouw SOC 2 als onderdeel van hun vendor risk management. Zonder SOC 2 kunnen ze je niet als vendor accepteren.

Shared responsibility model: Je bent verantwoordelijk voor security OF the cloud (physical, network, hypervisor). Klant is verantwoordelijk voor security IN the cloud (their apps, data). Je SOC 2 toont dat jouw deel secure is.

Competitive necessity: AWS, Azure, GCP hebben SOC 2. Kleinere cloud providers ook. Zonder SOC 2 kun je niet concurreren. “Why should we choose you over AWS?” Antwoord moet minstens zijn: “We hebben dezelfde compliance.”

Cloud-specifieke controls

1. Physical Security (kritiek voor eigen datacenter)

Als je eigen hardware hebt, is fysieke beveiliging major onderdeel.

Controls:

• Perimeter security: Fencing, gates, security guards
• Access control: Badge systems, biometric (fingerprint/retina)
• Visitor management: Log, escort requirement, temporary badges
• Surveillance: 24/7 camera’s, recording retention (90 days+)
• Environmental: Fire suppression, HVAC, power (UPS, generators)
• Asset tracking: Server inventory, decommissioning procedures

Auditor vraagt:

• “Show me datacenter access logs. Who entered last 6 months?”
• “How do you handle visitor access?”
• “What happens if unauthorized person enters?”
• “Show me camera footage (sample).”

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

• Vendor’s SOC 2 rapport hebben
• Jouw access controls binnen je cage/rack
• Visitatie logs bijhouden
• Auditor wil jouw vendor’s SOC 2 zien

Als je full cloud bent (AWS/Azure/GCP): Fysieke security is AWS/Azure/GCP’s verantwoordelijkheid. Auditor accepteert hun SOC 2 als evidence. Jouw scope: logical access, niet fysieke access.

2. Hypervisor en Virtualization Security

Je draait klanten in VMs of containers. Hoe isoleer je ze?

Controls:

• Hypervisor hardening: ESXi, KVM, Hyper-V up-to-date, patched
• VM isolation: Klant A’s VM kan niet klant B’s VM benaderen
• Resource allocation: CPU/memory limits per tenant (prevent noisy neighbor)
• Network segmentation: VLANs, VPCs per klant
• Escape prevention: Hypervisor vulnerabilities worden snel gepatched

Auditor vraagt:

• “Explain your virtualization architecture.”
• “How do you prevent VM escape?”
• “Show me network isolation. Can VM A reach VM B’s network?”
• “What if vulnerability in hypervisor is found? Timeline to patch?”

Bewijs:

• Architecture diagram (hypervisor, networking)
• Patch management logs (hypervisor updates)
• Network segmentation config
• Penetration test: attempted VM escape (should fail)

Best practice: Use hardware-level isolation waar mogelijk (Intel VT-x, AMD-V). Gebruik namespaces en cgroups voor containers. Regular security audits van hypervisor config.

3. Network Security en DDoS Protection

Je netwerk is public-facing. DDoS attacks zijn realiteit.

Controls:

• DDoS mitigation: Scrubbing centers, rate limiting, null routing
• Firewalls: Stateful firewalls, default deny
• IDS/IPS: Intrusion detection/prevention
• Traffic monitoring: NetFlow, anomaly detection
• Bandwidth management: QoS, traffic shaping
• Peering: Diverse upstream providers (redundancy)

Auditor vraagt:

• “What’s your DDoS mitigation strategy?”
• “Show me recent DDoS attack (if any) and how you handled it.”
• “How do you protect customer traffic?”
• “What monitoring do you have?”

Bewijs:

• DDoS mitigation documentation
• Network diagrams
• Incident logs (DDoS attacks)
• Monitoring dashboards

Availability focus: DDoS is availability risk. Auditor checkt of je prepared bent. Je moet kunnen aantonen: “We had DDoS attack, mitigated binnen X minutes, customer impact was Y.”

4. Multi-tenant Data Isolation

Je klanten delen infrastructure. Hoe voorkom je data leakage?

Controls:

• Storage isolation: Separate volumes, encryption keys per tenant
• Database isolation: Separate databases or strong schema-level isolation
• Backup isolation: Tenant A’s backup niet accessible door tenant B
• Network isolation: VPCs, security groups, firewalls
• Metadata separation: Even metadata (logs, billing) is tenant-isolated

Auditor vraagt:

• “How do you ensure tenant A can’t see tenant B’s data?”
• “Show me storage architecture.”
• “What happens if misconfiguration occurs?”
• “Do you have automated checks for tenant isolation?”

Bewijs:

• Architecture diagrams
• Code/config reviews: tenant filtering enforced
• Automated tests: cross-tenant access attempts (should fail)
• Penetration test findings

5. Customer Access Management

Klanten hebben access tot je portal, API, or infrastructure. Hoe manage je that?

Controls:

• MFA: Verplicht voor all customer accounts
• RBAC: Customers kunnen roles defineren (admin, user, read-only)
• API keys: Rotation capability, scoped permissions
• Access logs: All customer actions logged
• Session management: Timeouts, secure tokens

Auditor vraagt:

• “Show me customer login process.”
• “Is MFA enforced?” (yes)
• “Can customers see other customers’ data?” (no)
• “Show me API authentication.”

Bewijs:

• Customer portal screenshots
• MFA enforcement config
• API docs (authentication requirements)
• Access logs

6. Incident Response for Infrastructure

Incidents in cloud/hosting have wider impact (multiple customers).

Controls:

• Incident classification: Severity levels (SEV1, SEV2, etc.)
• Escalation matrix: Who to call for what severity
• Customer communication: Transparency during incidents (status page)
• Postmortems: After every major incident, document root cause
• SLA credits: If SLA breached, customer gets credit

Auditor vraagt:

• “Show me recent infrastructure incident.”
• “How did you communicate with customers?”
• “What was root cause? What did you fix?”
• “Show me postmortem document.”

Bewijs:

• Incident log (last 12 months)
• Sample incident + postmortem
• Customer communications (status page updates)
• Remediation actions

StatusPage is critical: Public status page (StatusPage.io, Atlassian Statuspage) waar customers real-time updates zien. Auditor verwacht dit voor Availability.

7. Capacity Planning en Scaling

Je moet vooruit plannen. Customer growth, seasonal spikes.

Controls:

• Resource monitoring: CPU, memory, disk, bandwidth per datacenter/region
• Forecasting: Quarterly capacity reviews, trend analysis
• Scaling procedures: Auto-scaling waar mogelijk, manual scaling documented
• Threshold alerting: 80% capacity = plan expansion
• Lead times: Know how long it takes to add capacity (order hardware, provision)

Auditor vraagt:

• “How do you plan for capacity?”
• “Show me recent capacity review.”
• “What happens if you hit capacity limit?”
• “Have you ever run out of capacity? How did you handle?”

Bewijs:

• Quarterly capacity review meeting notes
• Resource utilization graphs (6-12 months)
• Scaling events (added capacity)
• Customer communications (if capacity issues occurred)

8. Data Retention and Secure Decommissioning

Servers, disks worden decommissioned. Customer data must be securely wiped.

Controls:

• Data deletion policy: Customer data deleted within X days after contract end
• Disk wiping: DOD 5220.22-M standard or better (3+ pass wipe)
• Physical destruction: Disks that can’t be wiped are shredded
• Certificate of destruction: For regulatory/compliance customers
• Asset disposal log: Track decommissioned hardware

Auditor vraagt:

• “Show me decommissioning process.”
• “How do you wipe disks?”
• “Show me recent decommissioning log.”
• “What about failed disks? How are those handled?”

Bewijs:

• Decommissioning procedure document
• Sample decommissioning log
• Certificate of destruction (if physical destruction)
• Vendor contracts (if using third-party disposal)

Controls die extra belangrijk zijn voor cloud

Backup and Disaster Recovery (Super Critical)

Why extra critical: Je hosten data voor honderden/duizenden klanten. Backups falen = catastrofe.

Controls:

• Automated daily backups (per customer)
• Off-site backup storage (different region/provider)
• Backup encryption (at rest and in transit)
• Regular restore tests: Weekly (sample), monthly (full restore test)
• Backup monitoring: alerts als backup faalt
• Retention: 30 days daily, 12 months weekly

Auditor checkt:

• “Show me backup logs (6 months).”
• “When was last restore test?” (should be recent)
• “Show me successful restore.” (demo or evidence)
• “What if backup fails?” (alerts + investigation)

Veelgemaakte fout: Backups draaien, maar never tested. Customer vraagt restore, fails. Auditor hears this story, big finding. Test your backups religiously.

SLA Monitoring (Critical for Availability)

Why extra critical: Je hebt waarschijnlijk 99.9% or 99.95% SLA. Auditor gaat dit checken.

Controls:

• External uptime monitoring (not just internal)
• SLA reporting: monthly reports to customers
• Downtime tracking: all incidents logged
• Root cause analysis: for every outage
• SLA credits: automated or manual process

Auditor checkt:

• “Show me 12 months uptime data.”
• “Did you hit your SLA?” (if no: waarom? wat deed je?)
• “Show me customer SLA reports.”
• “How do you calculate uptime?” (methodology)

Availability targets:

If je SLA is 99.9% en je had 2 uur downtime in één maand, je breached. Auditor wil weten: customer compensated? Root cause fixed?

Change Management (Extra Rigorous)

Why extra critical: Changes impact alle customers. Bad change = mass outage.

Controls:

• Maintenance windows: announced 72h+ advance
• Change approval: senior engineer + manager approval
• Testing: staging environment that mirrors production
• Rollback plan: always have rollback ready
• Gradual rollout: canary deployments, blue/green
• Monitoring during/after change: extra vigilance
• Emergency change process: for critical security patches

Auditor checkt:

• Sample 20 changes: approval? testing? rollback plan?
• Failed change: how did you rollback? Customer impact?
• Emergency change: was it really emergency? Documented?

Best practice: Immutable infrastructure (containers, Kubernetes). Changes are new deployments, not in-place updates. Rollback = switch back to old deployment. Much safer.

Scope considerations voor cloud providers

Wat in scope?

Must include:

• Hosting infrastructure (servers, network, storage)
• Customer portals (billing, management interface)
• APIs voor customer management
• Support systems (ticketing, customer communication)

Consider including:

• Monitoring and logging systems
• Backup infrastructure
• Security tools (SIEM, IDS/IPS)

Can exclude (but carefully):

• Internal HR systems (unless HR has access to production)
• Marketing website (separate from customer platform)
• Development/test environments (if completely isolated)

Trust Services Criteria voor cloud

Typical choice: Security + Availability + Confidentiality

Security: Baseline, je bent secure tegen hackers Availability: Your core value prop is uptime Confidentiality: Customer data moet confidential blijven

Consider also: Processing Integrity: If je doet billing/metering for customers Privacy: If je collects PII beyond basic contact info

Heraudit en continuous compliance

Jaarlijks vernieuwen: Cloud/hosting environments change vaak. New datacenters, new services, acquisitions. Heraudit moet dit reflecteren.

Scope updates: Als je nieuwe dienst lanceert (bijv. managed database), moet die in scope volgende audit? Ja, als customers er data in stoppen.

Continuous monitoring: Tools zoals Drata, Vanta helpen, maar voor infrastructure is het complexer. Je hebt waarschijnlijk custom scripts nodig om compliance te monitoren.

Kosten voor cloud providers

Higher than SaaS: Cloud providers hebben vaak hogere audit kosten door:

• Fysieke security te auditen (datacenter visits)
• Meer systemen in scope
• Complexere infrastructure
• Multiple locations (if meerdere datacenters)

Typical costs (Type II):

• Small cloud provider (1 datacenter, onder 50 medewerkers): €50k-€80k
• Medium (2-3 datacenters, 50-200 medewerkers): €80k-€150k
• Large (multiple regions, 200+ medewerkers): €150k-€300k+

Add consultancy, tooling, internal time: total €100k-€400k+ eerste jaar.

Checklist voor cloud providers

Before SOC 2:

Physical:

• Datacenter access controls (badges, visitors, cameras)
• Environmental controls (fire, HVAC, power)
• Asset tracking en decommissioning

Infrastructure:

• Hypervisor hardened en patched
• Network segmentation per tenant
• DDoS mitigation
• Firewall rules documented
• IDS/IPS deployed

Data:

• Tenant isolation tested (pentests)
• Encryption at rest + in transit
• Backups automated + tested (restore tests)
• Data deletion procedures

Operations:

• Change management process
• Incident response plan + testing
• SLA monitoring en reporting
• Capacity planning quarterly
• Status page for customer transparency

Vendor:

• Upstream providers (ISPs, power, colocation) hebben SOC 2
• Hardware vendors documented
• Decommissioning vendor (if used)

Als je 80%+ checked, je bent 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