Skip to Content
SOC 2Voor SaaS-bedrijven

SOC 2 voor SaaS-bedrijven

Je bouwt software-as-a-service. Klanten vertrouwen je met hun data. Amerikaanse enterprise vraagt om SOC 2. Deze pagina behandelt SaaS-specifieke situaties: multi-tenancy, API security, customer data isolation, en scaling zonder security te verliezen. De AICPA Trust Services Criteria  zijn specifiek ontworpen voor service-organisaties zoals SaaS-bedrijven.

75% van SOC 2 audits zijn voor SaaS-bedrijven. Het framework is letterlijk ontworpen voor jullie. De belangrijkste vraag die auditors stellen: “Hoe isoleer je klant A’s data van klant B?” De rest volgt daaruit.

Waarom SaaS-bedrijven SOC 2 nodig hebben

Enterprise sales blokkade: Je komt in gesprek met Fortune 500 bedrijf. Procurement stuurt je security questionnaire. Vraag 1: “Do you have SOC 2 Type II?” Als antwoord nee is, gaat 80% van enterprises niet verder. SOC 2 is het toegangsbewijs.

VC due diligence: Series B en later: investors vragen om SOC 2. Het toont dat je mature bent op security, schaalbaar kunt groeien, en enterprise-ready bent. Het verhoogt je valuatie.

Competitor comparison: Je concurreert met gevestigde SaaS-spelers. Die hebben SOC 2. Jij niet. Guess wie de deal wint? Security is een competitive moat.

Scaling efficiency: Zonder SOC 2: elke nieuwe enterprise klant stuurt 200-vragen security questionnaire. Jouw sales engineer vult 40 uur in. Met SOC 2: “Here’s our report, see section X.” Deal gaat sneller door.

De belangrijkste SaaS-specifieke controls

1. Multi-tenancy en data isolation

Dit is het hart van SaaS security. Hoe zorg je dat klant A’s data niet door klant B gezien kan worden?

Architectuur patterns:

  • Database-level isolation: Elke klant eigen database (AWS RDS instances). Most secure, maar duurder en complexer om te schalen.
  • Schema-level isolation: Shared database, elke klant eigen schema (PostgreSQL schemas). Balans tussen security en efficiency.
  • Row-level isolation: Shared tables, elke row heeft tenant_id. Efficiënt, maar meer room for errors (developers moeten altijd tenant filtering implementeren).

Auditor vraagt:

  • “Show me your data model. Hoe voorkom je dat tenant A tenant B’s data ziet?”
  • “Laat een SQL query zien die customer data ophaalt. Is er tenant filtering?”
  • “Wat gebeurt er als developer vergeet WHERE tenant_id = clause?”
  • “Are there database-level constraints? (RLS policies, views, triggers)”

Bewijs:

  • Architecture diagram van tenancy model
  • Code review process: peer review checks voor tenant filtering
  • Automated tests: elke data access query heeft test die cross-tenant leak voorkomt
  • Penetration test: tester probeert cross-tenant access (moet falen)

Best practice: Gebruik Row-Level Security (RLS) in PostgreSQL of equivalent in je database. Dit is second layer defense. Zelfs als developer vergeet WHERE clause, RLS blokkeert cross-tenant access op database-level.

2. API security en rate limiting

Je SaaS heeft API’s. Klanten gebruiken ze, maar ook: kwaadwillenden proberen ze te misbruiken.

Controls:

  • Authentication: API keys of OAuth tokens vereist voor alle endpoints
  • Authorization: Token scope bepaalt wat je mag doen (read-only vs full access)
  • Rate limiting: X requests per minute per tenant, voorkomt abuse/DDoS
  • Input validation: Alle input wordt gesanitized (prevent SQL injection, XSS)
  • API versioning: Oude versies worden deprecated met notice period
  • API logging: Elke call gelogd: who, what, when, response code

Auditor vraagt:

  • “Can I call your API without auth?” (moet nee zijn)
  • “What happens if I send 10,000 requests in 1 second?” (rate limiter moet kicken)
  • “Show me logs van API calls. Zie ik anomalies?”
  • “How do you handle API key rotation?”

Bewijs:

  • API documentation met authentication requirements
  • Rate limiting config screenshots
  • Sample API logs
  • Rate limiting triggered events (shows it works)

SaaS-specific risk: API’s zijn public-facing. Je attack surface is groot. Extra security layers zijn needed:

  • Web Application Firewall (WAF) voor common attacks
  • Bot detection (Cloudflare Bot Management, PerimeterX)
  • Anomaly detection (sudden spike in API calls from één user)

3. Customer data export en portability

GDPR en goede customer experience: klanten moeten hun data kunnen exporteren.

Controls:

  • Self-service export: UI button “Download my data”
  • Export formats: JSON, CSV, Excel (machine-readable)
  • Filtered by tenant: export bevat alleen hun data
  • Audit trail: log wie, wanneer geëxporteerd
  • Throttling: grote exports via async job (email link when ready)

Auditor vraagt:

  • “Show me the export feature.”
  • “Doe een test export. Bevat het only dat tenant’s data?”
  • “What if tenant B requests tenant A’s data?” (moet rejected worden)

Bewijs:

  • Export feature demo
  • Test export + verification dat alleen tenant’s data erin zit
  • Audit logs van exports

Business continuity angle: Export is ook onderdeel van Availability. Als jouw platform down gaat, kunnen klanten hun data uit je laatste backup halen? Auditor kan dit linken aan DR (Disaster Recovery).

4. Secrets management (voor SaaS met integrations)

Je SaaS integreert met Salesforce, Slack, Stripe, etc. Je slaat customer’s OAuth tokens op. Hoe beveilig je die?

Controls:

  • Encryption at rest: Tokens encrypted in database (app-level of database-level)
  • Encryption in transit: Tokens altijd over HTTPS
  • Access controls: Alleen authorized services kunnen tokens decrypten
  • Rotation: Automatic token refresh (OAuth refresh tokens)
  • Audit: Log elke access tot encrypted tokens
  • Secrets manager: Gebruik vault (HashiCorp Vault, AWS Secrets Manager)

Auditor vraagt:

  • “Where do you store customer OAuth tokens?”
  • “Are they encrypted?” (ja)
  • “Who can decrypt them?” (only authorized microservices, niet developers)
  • “Show me audit trail of token access.”

Bewijs:

  • Secrets manager configuration
  • Encryption key management policies
  • Audit logs van secret access
  • Code review: geen hardcoded secrets (linter checkt dit)

Veelgemaakte fout: Tokens encrypted, maar encryption keys zijn in environment variables in GitHub repo. Auditor ziet dit. “So anyone with GitHub access can decrypt tokens?” Ja. Finding.

5. Feature flags en gradual rollouts

Je doet continuous deployment. Nieuwe features gaan via feature flags. Hoe voorkom je dat een bug alle klanten raakt?

Controls:

  • Feature flags systeem (LaunchDarkly, Unleash, custom)
  • Gradual rollout: eerst intern, dan 1% klanten, dan 10%, then 100%
  • Kill switch: feature kan instant disabled als er problemen zijn
  • Monitoring per feature: error rates, latency, per flag
  • Documentation: welke flags zijn er, wat doen ze, wie mag ze togglen

Auditor vraagt:

  • “Show me recent feature rollout. Was it gradual?”
  • “What happens if a feature causes errors?” (kill switch)
  • “Who can toggle production feature flags?” (authorized personnel only)

Bewijs:

  • Feature flag dashboard
  • Sample gradual rollout (timeline, percentage, metrics)
  • Kill switch event (feature disabled due to issue)
  • Access logs: wie togglede flags

Why auditor cares: Processing Integrity (data correctness) en Availability (uptime). Een bug die 100% klanten raakt is erger dan 1% raakt. Feature flags zijn risk mitigation.

6. Customer-specific configurations

Enterprise klanten vragen custom configs: SSO, IP whitelisting, custom domains, data residency.

Controls:

  • Configuration management: where zijn configs opgeslagen (database, config files)
  • Validation: configs worden getest before deployment
  • Access controls: alleen authorized personnel kan configs wijzigen
  • Change log: alle config changes gelogd
  • Customer approval: enterprise configs alleen met customer approval

Auditor vraagt:

  • “Show me customer X’s config. How is it different from default?”
  • “What happens if you misconfigure customer Y’s SSO?” (they can’t login)
  • “How do you test configs before deploying?”
  • “Show me change history of configs.”

Bewijs:

  • Config management tool (Terraform, custom admin panel)
  • Sample config change: ticket, approval, test, deploy, verify
  • Change logs
  • Rollback capability (if config breaks something)

7. Customer onboarding security

New customer signs up. Hoe zorg je dat ze veilig starten?

Controls:

  • Email verification verplicht
  • Initial password requirements (strong password enforced)
  • MFA encouragement (prompt to enable)
  • Onboarding checklist: security settings configured
  • Default settings: secure-by-default (bijv. SSO preferred over password)

Auditor vraagt:

  • “Show me customer signup flow.”
  • “Can I signup with weak password?” (nee, enforced)
  • “What data is collected? Is there privacy policy shown?”
  • “Are customers encouraged to enable MFA?”

Bewijs:

  • Signup flow screenshots
  • Password requirements enforced (technical demonstration)
  • Onboarding emails with security tips
  • Analytics: X% of customers enable MFA within 7 days

8. Scaling without compromising security

Je groeit van 10 naar 100 naar 1000 klanten. Security moet mee-schalen.

Controls:

  • Automated security checks in CI/CD (code scanning, dependency checks)
  • Infrastructure as Code (Terraform): security configs consistent across environments
  • Automated compliance monitoring (Vanta, Drata): continuous control checks
  • Security champions program: engineers trained on security, distributed ownership
  • Threat modeling: before nieuwe features, assess security implications

Auditor vraagt:

  • “How do you ensure security at scale?”
  • “Are security checks automated?” (ja, in CI/CD)
  • “What happens if engineer deploys insecure code?” (CI/CD blocks it)

Bewijs:

  • CI/CD pipeline config (security scans)
  • Blocked deployments (code with vulnerabilities rejected)
  • IaC templates (Terraform modules with security defaults)
  • Security champion training records

Common SaaS auditor questions

“How do you handle customer churn and data deletion?” Je moet aantonen:

  • Customer data wordt verwijderd na churn (binnen X dagen)
  • Hard delete, niet soft delete (GDPR requirement)
  • Backups: data ook uit backups verwijderd (na retention period)
  • Verification: customer kan verification request doen (data is weg)

“What if your SaaS gets acquired? What happens to customer data?” Je moet hebben:

  • Data ownership clause in terms of service (data blijft van klant)
  • Acquisition scenario in privacy policy (notification verplicht)
  • Data portability (customers kunnen data meenemen)

“How do you handle multi-region customers?” Auditor checkt:

  • Data residency: kun je data in EU houden voor EU customers?
  • Cross-region replication: is data encrypted tijdens transfer?
  • Compliance: GDPR, data protection laws per region

“What about mobile apps? Are those in scope?” Als je mobile app hebt:

  • App security testing (OWASP Mobile Top 10)
  • API security (app communiceert via API)
  • Data storage op device: encrypted?
  • MDM voor company-owned devices

Tips voor SaaS-specifieke scope

Begin met core product

Je eerste SOC 2: focus op core SaaS platform. Exclude:

  • Internal tools (Jira, Slack, HR systems)
  • Marketing website (WordPress blog)
  • Mobile apps (als die er zijn, voeg later toe)
  • Legacy features (als je deprecating bent)

Why: Smaller scope = sneller, goedkoper, makkelijker te bewijzen. Je krijgt ervaring, next year breid je uit.

Kies Security + Availability

Voor SaaS zijn deze twee criteria most relevant:

  • Security: Klanten data is veilig
  • Availability: Jouw SaaS is beschikbaar (99.9% uptime SLA)

Skip first time:

  • Processing Integrity (unless je doet billing/berekeningen)
  • Confidentiality (unless je zeer gevoelige proprietary data verwerkt)
  • Privacy (unless je consumer-facing bent met veel PII)

Je kunt altijd later criteria toevoegen.

Type II is must-have voor enterprise

Type I is oké voor SMB klanten, maar enterprise wil Type II. Als je target Fortune 500, ga direct voor Type II. Observatieperiode 6 maanden is acceptabel (12 maanden is beter, maar 6 is OK).

Kosten en tijdlijn voor SaaS

Small SaaS (1-25 engineers)

Kosten:

  • Audit: €30k-€50k (Type II)
  • Tooling: €8k-€15k (Vanta/Drata)
  • Consultant: €10k-€20k (readiness + guidance)
  • Internal: 300-500 uur (CTO/lead engineer) Totaal eerste jaar: €60k-€100k

Timeline: 9-12 maanden

Funding stage: Series A+ (pre-Series A is vaak te vroeg tenzij enterprise deal blocked)

Medium SaaS (25-100 engineers)

Kosten:

  • Audit: €50k-€80k
  • Tooling: €12k-€20k
  • Consultant: €15k-€30k
  • Internal: 400-600 uur Totaal: €90k-€150k

Timeline: 10-14 maanden

Funding stage: Series B+ (enterprise expansion phase)

Large SaaS (100+ engineers)

Kosten:

  • Audit: €70k-€150k+
  • Tooling: €20k-€40k
  • Consultant: vaak intern compliance team
  • Internal: 600-1000 uur Totaal: €120k-€250k+

Timeline: 12-18 maanden

Funding stage: Series C+, pre-IPO (compliance is expected)

Checklist voor SaaS security

Before je SOC 2 start, check deze basics:

Infrastructure:

  • Cloud provider (AWS/Azure/GCP) met SOC 2 rapport
  • MFA op alle cloud accounts
  • Production apart van development
  • Encryption at rest + in transit
  • Backups automated en tested

Application:

  • Multi-tenancy model designed en tested
  • API authentication vereist
  • Rate limiting geïmplementeerd
  • Input validation overal
  • Security headers (CSP, HSTS, etc.)

Organizational:

  • Security awareness training
  • Incident response plan
  • Vendor management (SOC 2 van critical vendors)
  • Access reviews quarterly
  • Change management process

Evidence:

  • Logging centralized (SIEM)
  • Vulnerability scans weekly
  • Penetration test annual
  • Policies documented
  • Compliance tool (Vanta/Drata) collecting evidence

Als je 80%+ hebt, ben je klaar om SOC 2 te starten. Minder? Werk eerst aan basics.

Meer informatie

SOC 2 vs. SOC 1Voor cloud providers