Trust Services Criteria: waar wordt je op getest?
SOC 2 is niet één standaard met een vaste checklist. Het is een framework van de AICPA met vijf categorieën: de Trust Services Criteria (TSC) . Je kiest welke relevant zijn voor jouw business. Security is verplicht, de rest is optioneel. Klinkt simpel, maar de keuze heeft grote impact op scope, kosten en wat je moet implementeren.
Dit artikel legt elk criterium uit: wat het betekent, welke controls erbij horen, en wanneer je het kiest.
De vijf criteria in het kort
| Criterium | Verplicht? | Focus | Voor wie? |
|---|---|---|---|
| Security | Ja, altijd | Bescherming tegen ongeautoriseerde toegang | Iedereen |
| Availability | Nee | Systeem is beschikbaar wanneer nodig | SaaS met SLA, critical systems |
| Processing Integrity | Nee | Data wordt compleet, geldig, accuraat verwerkt | Financiële diensten, transactieverwerking |
| Confidentiality | Nee | Vertrouwelijke informatie is beschermd | Bedrijven met proprietary data, trade secrets |
| Privacy | Nee | Persoonlijke gegevens worden correct behandeld | Consumer apps, GDPR-gevoelige data |
In 2025 kiest 100% Security (verplicht), 75% Availability, 64% Confidentiality, 30% Processing Integrity, en 20% Privacy. De trend: bredere scope dan vroeger. Waar bedrijven vroeger Security-only deden, kiezen ze nu 2-3 criteria.
Security (Common Criteria): de basis
Wat het is: Bescherming van je systemen en data tegen ongeautoriseerde toegang, gebruik, disclosure, disruption, modification, of destruction. In mensentaal: hackers buiten houden, data veilig houden, systemen beschermen.
Dit is het enige verplichte criterium. Alles draait om de CIA-triad: Confidentiality, Integrity, Availability op security-niveau.
Wat wordt getest:
Access controls
- Multi-Factor Authentication (MFA) op alle kritieke systemen
- Role-Based Access Control (RBAC): juiste toegang voor juiste mensen
- Least privilege principle: niemand heeft meer rechten dan nodig
- Regular access reviews: elk kwartaal checken wie nog toegang heeft
- Onboarding/offboarding procedures: binnen 24 uur accounts aanmaken/sluiten
Network security
- Firewalls met documented rules
- Network segmentation (productie apart van development)
- Intrusion Detection/Prevention Systems (IDS/IPS)
- VPN voor remote access
- DDoS protection
Encryption
- Data at rest encrypted (databases, storage, backups)
- Data in transit encrypted (TLS 1.2+, geen legacy protocols)
- Encryption key management (wie heeft toegang tot keys?)
Vulnerability en patch management
- Weekly automated vulnerability scans
- Kritieke patches binnen 30 dagen (vaak sneller)
- Dependency scanning voor third-party libraries
- Annual penetration testing door externe partij
Logging en monitoring
- Centralized logging (alle logs verzameld in SIEM)
- Log retention minimaal 90 dagen (vaak 1 jaar)
- Monitoring en alerting voor security events
- Log review procedures (wie checkt de logs?)
Incident response
- Documented incident response plan
- Assigned roles (incident commander, communications lead, etc.)
- Regular testing (minimaal annual tabletop exercise)
- Breach notification procedures (klanten, toezichthouders)
Physical security
- Access controls voor datacenters (als je eigen hardware hebt)
- Bij cloud: SOC 2 van je cloud provider (AWS, Azure, GCP) volstaat vaak
- Office security (badge systems, visitor procedures)
Change management
- All production changes via ticketing system
- Peer review en approval vereist
- Testing procedures voor changes
- Rollback procedures als iets fout gaat
Voorbeelden van controls:
Een SaaS-bedrijf op AWS:
- MFA verplicht in AWS Console, GitHub, Google Workspace
- Engineers hebben geen productie-toegang, alleen via bastion host met logging
- Databases encrypted met AWS KMS, keys roteren jaarlijks
- Dependabot scant dependencies daily, kritieke vulnerabilities binnen 48u gepatched
- DataDog verzamelt alle logs, PagerDuty alert bij suspicious activity
- Changes via Jira ticket + GitHub PR + LGTM van senior engineer
Security is de basis. Als je Security niet op orde hebt, krijg je geen SOC 2. Alle andere criteria bouwen hierop voort.
Availability: uptime en disaster recovery
Wat het is: Je systeem, product, of service is beschikbaar voor gebruik zoals overeengekomen. Als je een SLA belooft (“99.9% uptime”), moet je kunnen bewijzen dat je dat haalt. En als het down gaat, heb je procedures om het snel weer operationeel te krijgen.
Wanneer kiezen:
- Je hebt een SLA in je contracten
- Downtime heeft direct business impact voor klanten
- Je hebt mission-critical systems
- Je verkoopt aan enterprise klanten die 24/7 beschikbaarheid eisen
Wat wordt getest:
Uptime monitoring
- Real-time monitoring van alle critical services
- Alerting bij downtime of performance degradation
- SLA reporting: kunnen we bewijzen dat we 99.9% haalden?
Capacity planning
- Resource monitoring (CPU, memory, disk, bandwidth)
- Forecasting en scaling procedures
- Load testing om limieten te kennen
Disaster recovery
- Documented disaster recovery plan
- Recovery Time Objective (RTO): binnen hoeveel tijd ben je weer live?
- Recovery Point Objective (RPO): hoeveel data-verlies is acceptabel?
- Regular DR testing (minimaal annual)
Backups
- Automated daily backups
- Backups stored in separate geographic region
- Regular restore testing (quarterly): kunnen we echt restoren?
- Backup retention policy documented
Redundancy
- No single points of failure in critical systems
- Load balancers, multiple availability zones
- Database replication/clustering
- Failover procedures documented en tested
Voorbeelden van controls:
Een SaaS-platform met 99.9% SLA:
- Multi-AZ deployment in AWS (us-east-1a, 1b, 1c)
- RDS database met Multi-AZ replication
- Application Load Balancer distribueert traffic
- Daily automated backups naar S3 in verschillende regio
- Quarterly restore tests (laatste test: 2025-12-15, successful)
- StatusPage.io voor uptime transparency
- PagerDuty escalation: critical alert → on-call engineer binnen 15 min
Availability kiezen betekent: je moet je SLA echt halen. Auditor checkt je uptime metrics. Als je 99.9% belooft en 98% haalt, is dat een finding.
Processing Integrity: data wordt correct verwerkt
Wat het is: Data wordt compleet, geldig, accuraat en tijdig verwerkt. In de juiste volgorde, zonder errors, zonder data loss. Als je input X verwerkt, is output Y consistent en correct.
Wanneer kiezen:
- Je verwerkt financiële transacties
- Je doet berekeningen waar klanten op vertrouwen (billing, analytics, reporting)
- Data accuracy is business-critical
- Je bent een payment processor, accounting software, financial platform
Wat wordt getest:
Data validation
- Input validation: data wordt gecheckt voordat verwerking
- Error handling: wat gebeurt er bij invalid data?
- Data integrity checks: checksums, hashes, validation rules
Processing controls
- Completeness checks: alle records verwerkt?
- Duplicate detection: geen dubbele verwerking?
- Sequencing: data in juiste volgorde verwerkt?
- Reconciliation procedures: input vs output matches?
Quality assurance
- Automated testing van processing logic
- Regular audits van output quality
- Exception handling en logging
- Correction procedures voor errors
Timeliness
- Processing happens within defined timeframes
- SLA voor processing speed
- Monitoring van processing delays
- Queue management voor workloads
Voorbeelden van controls:
Een payment processor:
- Elke transaction krijgt unique ID, logged in multiple systems
- End-of-day reconciliation: total input moet match total output
- Automated checks: transaction amount matches invoice amount
- Duplicate detection: same payment_id binnen 5 minuten = blocked
- Processing SLA: 95% van transactions binnen 2 seconden
- Failed transactions worden retry met exponential backoff
- Monthly reconciliation reports voor elke merchant
Voor wie is dit NIET relevant:
Als je een CRM bouwt, collaboration tool, of social media platform waar het gaat om “opslaan en tonen” maar niet om “correct berekenen,” is Processing Integrity waarschijnlijk overkill. Security en Confidentiality zijn dan relevanter.
Confidentiality: vertrouwelijke informatie beschermen
Wat het is: Informatie die als “confidential” is geclassificeerd wordt beschermd tegen ongeautoriseerde disclosure. Dit gaat verder dan Security: het gaat om data classification, wie mag wat zien, hoe deel je vertrouwelijk, hoe voorkom je data leaks.
Wanneer kiezen:
- Je verwerkt proprietary information van klanten (trade secrets, strategische data)
- Je hebt contractuele verplichtingen over confidentiality (NDA’s)
- Je bent in een sector waar data-leaks desastreus zijn (legal, finance, healthcare)
- Je klanten zijn competitief en willen niet dat hun data gelekt wordt
Wat wordt getest:
Data classification
- Documented data classification scheme (public, internal, confidential, restricted)
- Alle data is geclassificeerd
- Labels/tags op data zodat systemen weten hoe te behandelen
- Regular reviews van classificatie
Access controls
- Access based op need-to-know
- Confidential data alleen toegankelijk voor authorized personnel
- Separation of duties: geen single person kan alle vertrouwelijke data zien
- Logging van alle access tot confidential data
Data handling procedures
- Secure transfer procedures (encrypted channels)
- Secure storage (encryption, access controls)
- Data retention en destruction policies
- Clean desk policy (geen confidential prints rondslingeren)
Agreements
- NDA’s met employees en contractors
- DPA’s (Data Processing Agreements) met vendors
- Confidentiality clauses in customer contracts
Monitoring
- Data Loss Prevention (DLP) tools
- Monitoring van data exports (wie download large datasets?)
- Alerting bij unusual access patterns
Voorbeelden van controls:
Een legal tech platform:
- Data classification: case files = Confidential, billing = Internal, marketing = Public
- Access controls: lawyers alleen hun eigen cases, admins alleen metadata
- S3 buckets met restrictive policies, geen public access
- DLP rules in Google Workspace: no emailing confidential files to personal addresses
- Annual employee training over confidentiality
- NDA signed bij onboarding, reminder jaarlijks
- Audit log: elke access tot case file gelogd met user, timestamp, action
Overlap met Security: Ja, Confidentiality overlapt veel met Security. Het verschil: Security focust op “hackers buiten houden,” Confidentiality focust op “insiders en authorized users houden binnen hun lane.” Beide zijn belangrijk.
64% van SOC 2 rapporten bevat nu Confidentiality (was 34% in 2023). Dit is de snelst groeiende criterium. Reden: data breaches via insiders en vendors zijn toegenomen.
Privacy: persoonlijke gegevens correct behandelen
Wat het is: Persoonlijke informatie van individuen wordt verzameld, gebruikt, behouden, disclosed en disposed volgens je privacy policy en relevante wetgeving (GDPR, CCPA, etc.). Dit is de GDPR-achtige criterium van SOC 2.
Wanneer kiezen:
- Je verwerkt veel persoonsgegevens (namen, emails, adressen, health data, financial data)
- Je bent een consumer-facing app
- Je klanten zijn in Europa (GDPR) of California (CCPA)
- Je wilt GDPR compliance tonen aan Amerikaanse klanten die het niet snappen
Wat wordt getest:
Notice en consent
- Privacy policy is duidelijk en accessible
- Users worden geïnformeerd over data collection
- Consent wordt verkregen waar nodig (opt-in, niet opt-out)
- Cookie banners en tracking consent
Data collection
- Only collect wat je nodig hebt (data minimization)
- Documented purpose voor elke data point
- No secondary use zonder consent
Data quality
- Data is accuraat en up-to-date
- Users kunnen hun data inzien en corrigeren
- Procedures voor data accuracy
Data retention en deletion
- Retention policies: hoe lang bewaar je data?
- Automatic deletion na retention period
- Users kunnen data deletion request doen (right to be forgotten)
- Backup deletion procedures
Data subject rights
- Users kunnen access request doen (copy van hun data)
- Users kunnen portability request doen (data export)
- Users kunnen objection maken (stop verwerking)
- Response binnen 30 dagen (GDPR vereiste)
Third-party disclosure
- Documented welke vendors hebben access tot personal data
- DPA’s met alle processors
- Sub-processor lists publicly available
- Prior notice bij nieuwe sub-processors
Voorbeelden van controls:
Een consumer health app:
- Privacy policy in plain English, GDPR en CCPA compliant
- Cookie consent banner (strict mode: no tracking zonder consent)
- Data collection: alleen health metrics relevant voor app functionality
- Retention: inactive accounts auto-deleted na 2 jaar
- User dashboard: zie je eigen data, download button, delete account button
- Deletion request via email: processed binnen 7 dagen, confirmation sent
- Sub-processors list op website: AWS, SendGrid, Stripe
- DPA’s met alle vendors, reviewed annual
GDPR alignment: Privacy criterium is niet hetzelfde als GDPR, maar er is 70% overlap. Als je GDPR-compliant bent, heb je veel Privacy controls al. SOC 2 Privacy plus GDPR = je bent goed covered.
Welke criteria kies je? Praktische guide
SaaS
Typische SaaS-bedrijf
Aanbeveling: Security + Availability + Confidentiality
Waarom:
- Security: verplicht, basis van alles
- Availability: je hebt waarschijnlijk een SLA (99.9% uptime)
- Confidentiality: je klanten vertrouwen je met business-critical data
Skip (meestal):
- Processing Integrity: relevant alleen als je berekeningen doet (billing, analytics engine)
- Privacy: alleen als je consumer app bent of veel GDPR-data verwerkt
Kosten impact: +20-30% vs Security-only
Criteria later toevoegen
Je begint met Security-only. Jaar later: klanten vragen om Availability. Kan je dat toevoegen? Ja.
Process:
- Volgende audit: scope uitbreiden met Availability
- Auditor test alle Availability controls vanaf scratch
- Je krijgt update rapport met Security + Availability
- Kosten: +15-25% voor added criterium
Timing: Je kunt criteria toevoegen bij elke heraudit. Hoeft niet meteen het eerste jaar.
Advies: Begin pragmatisch (Security-only of Security + Availability). Als klanten specifiek om andere criteria vragen, breid dan uit. Niet proactief 5 criteria kiezen “omdat het kan.”
Kosten impact per criterium
| Criteria combinatie | Audit fees (midden-sized) | Implementatie effort |
|---|---|---|
| Security only | €45k-€60k | Baseline (100%) |
| Security + Availability | €52k-€72k | +15-20% |
| Security + Availability + Confidentiality | €60k-€85k | +25-35% |
| Security + Processing Integrity + Confidentiality | €62k-€90k | +30-40% |
| Alle vijf criteria | €75k-€110k+ | +50-70% |
Meer criteria = meer controls te implementeren, meer evidence te verzamelen, meer audit tijd. Kies strategisch.
Meer informatie
- Stappenplan – De 12 stappen naar SOC 2
- Kosten en tijdlijn – Wat kost het per criterium
- Het auditproces – Wat test de auditor precies
- Veelgebruikte controls – Concrete voorbeelden per criterium
- AICPA Trust Services Criteria – Officiële bron met alle points of focus