Veelgebruikte SOC 2 controls

SOC 2 is geen checklist met “installeer deze 47 tools.” Het is een framework waar je zelf invulling aan geeft. Deze pagina toont de meest voorkomende controls, wat ze betekenen, en hoe je ze praktisch implementeert.

Denk aan deze als building blocks. Je kiest wat relevant is voor jouw organisatie, implementeert het, en bewijst dat het werkt.

Security Controls (verplicht voor iedereen)

1. Multi-Factor Authentication (MFA)

Wat: Toegang tot kritieke systemen vereist tweede factor naast wachtwoord.

Implementatie:

• AWS/Azure/GCP: MFA verplicht op console access
• GitHub/GitLab: MFA verplicht op org-level
• Google Workspace/Office 365: MFA voor alle users
• Applicatie admin accounts: MFA vereist
• SSH/server access: key-based + optional TOTP

Tools:

• Google Authenticator (gratis)
• 1Password/LastPass MFA (€5/user/maand)
• Yubikey hardware tokens (€45 eenmalig)
• Duo Security (€3/user/maand)

Evidence:

• Screenshots van MFA settings (monthly)
• Audit logs van MFA-protected logins
• Policy document stating MFA requirement

Veelgemaakte fout: MFA “beschikbaar” maar niet “enforced.” Auditor checkt: kunnen users het uitzetten? Dat moet nee zijn.

2. Role-Based Access Control (RBAC)

Wat: Users krijgen toegang op basis van hun rol, niet ad-hoc. Principle of least privilege.

Implementatie:

• Defined roles: Admin, Developer, Support, ReadOnly
• Access matrix: welke rol heeft toegang tot welk systeem
• Geen shared accounts (geen “admin@company.com”)
• Quarterly access reviews: check of mensen nog juiste toegang hebben

Tools:

• AWS IAM roles en policies
• GitHub teams en permissions
• Google Workspace groups
• Okta/Auth0 voor app-level RBAC

Evidence:

• Access control matrix (Excel met wie mag wat)
• AWS IAM policy documents
• Screenshots van role assignments
• Quarterly access review meeting minutes

Voorbeeld matrix:

3. Onboarding en Offboarding procedures

Wat: Nieuwe medewerkers krijgen juiste toegang binnen X dagen. Vertrokken medewerkers verliezen toegang binnen 24 uur.

Implementatie: Onboarding:

• HR form triggers IT ticket
• Background check voordat toegang wordt gegeven
• NDA signed
• Security awareness training binnen 7 dagen
• Access provisioned volgens role
• Welcome email met policies

Offboarding:

• HR notifies IT van laatste werkdag
• Alle accounts disabled binnen 24 uur
• Hardware returned (laptop, badges)
• Exit interview (optional maar aanbevolen)

Tools:

• HRIS: BambooHR, Workday
• Ticketing: Jira Service Desk, Zendesk
• MDM: Jamf, Kandji (remote wipe capability)
• IAM: Okta (automated deprovisioning)

Evidence:

• Sample van 5-10 onboards: HR form, IT ticket, training completion, access grant email
• Sample van 5-10 offboards: termination notice, account disabled logs, hardware return receipt
• Policy document met tijdlijnen

Veelgemaakte fout: Laptop ophalen duurt 3 weken bij remote employee. Oké, maar account moet binnen 24u disabled zijn. Hardware is separate concern.

4. Logging en Monitoring

Wat: Alle belangrijke events worden gelogd. Logs worden gecentraliseerd en gemonitord voor suspicious activity.

Implementatie:

• Centralized logging (SIEM): alle logs naar één plek
• Log retention: minimaal 90 dagen, vaak 1 jaar
• Monitoring van authentication events, access changes, errors, security events
• Alerting voor critical events (failed logins, privilege escalation, data export)
• Weekly log review (automated + manual spot checks)

Tools:

• SIEM: Splunk, Datadog, ELK Stack, Sumo Logic
• Cloud-native: AWS CloudWatch, Azure Monitor, GCP Logging
• Security-focused: Panther, Lacework

Evidence:

• SIEM dashboard screenshots
• Log retention policy document
• Sample alerts + investigation notes
• Weekly log review reports

Wat loggen:

• Authentication: wie logt in, wanneer, waar vandaan, success/fail
• Authorization: access grants, role changes, permission elevations
• Data access: database queries, file downloads, API calls
• Changes: code deploys, infrastructure changes, config updates
• Security events: firewall blocks, IDS alerts, malware detection

5. Encryption

Wat: Data is encrypted at rest (on disk) en in transit (over network).

Implementatie: At rest:

• Database encryption (RDS, MongoDB Atlas, etc.)
• S3 bucket encryption (default encryption enabled)
• Laptop full-disk encryption (FileVault, BitLocker)
• Backup encryption

In transit:

• TLS 1.2+ for all external connections
• No legacy protocols (SSL 3.0, TLS 1.0/1.1)
• Internal traffic encrypted waar mogelijk (service mesh, VPN)
• Email encryption (opportunistic TLS)

Tools:

• Cloud provider native encryption (AWS KMS, Azure Key Vault)
• Certificate management: Let’s Encrypt, AWS Certificate Manager
• Laptop: FileVault (Mac), BitLocker (Windows)

Evidence:

• Screenshots van encryption settings
• Certificate validity checks
• Encryption key rotation logs
• SSL Labs scan results (A rating minimum)

Veelgemaakte fout: Encryption is aan, maar keys zijn niet managed. “Who has access to encryption keys?” is auditor vraag. Antwoord moet zijn: only authorized personnel, documented in policy.

6. Vulnerability en Patch Management

Wat: Systemen worden regelmatig gescand op vulnerabilities. Critical/high vulnerabilities worden snel gepatched.

Implementatie:

• Weekly automated vulnerability scans
• Dependency scanning voor code (npm audit, Snyk, Dependabot)
• OS patch management (automated updates waar mogelijk)
• SLA’s: Critical 7 dagen, High 30 dagen, Medium 90 dagen
• Exception process: als patch niet mogelijk, documented risk acceptance

Tools:

• Vulnerability scanning: Tenable Nessus, Qualys, Rapid7
• Dependency scanning: Snyk, GitHub Dependabot, WhiteSource
• Patch management: AWS Systems Manager, WSUS, Ansible

Evidence:

• Weekly scan reports (6 maanden)
• Patch deployment logs
• Risk acceptance documents (voor vulnerabilities die niet gepatched zijn)
• Metrics: average time to patch, % compliance met SLA

Veelgemaakte fout: Scans draaien, vulnerabilities worden gevonden, maar niet opgevolgd. Auditor ziet critical vulnerability van 90 dagen oud. “Waarom niet gepatched?” Geen goed antwoord = finding.

7. Incident Response

Wat: Je hebt een plan voor security incidents. Je weet wat te doen, wie te bellen, hoe te communiceren.

Implementatie:

• Incident Response Plan document
• Defined roles: Incident Commander, Communications Lead, Technical Lead
• Escalation procedures
• Communication templates (internal, customer, press)
• Annual testing (tabletop exercise)
• Incident log (alle incidents documented)

Tools:

• Incident management: PagerDuty, Opsgenie, VictorOps
• Communication: Slack incident channels, status page
• Forensics: Packet captures, log analysis tools

Evidence:

• Incident Response Plan document
• Tabletop exercise meeting notes
• Incident log (real incidents if any, with postmortems)
• Training records (who was trained on IRP)

Wat loggen per incident:

• Date/time detected
• Description
• Severity
• Assigned to
• Actions taken
• Resolution
• Root cause
• Preventive measures

8. Change Management

Wat: Productie changes gaan via gedocumenteerd proces. Geen cowboy deploys.

Implementatie:

• Alle changes via ticketing system (Jira, GitHub Issues)
• Peer review vereist (code review, infrastructure review)
• Approval workflow (depends on change size)
• Testing procedures
• Deployment window (maintenance windows voor risky changes)
• Rollback plan
• Post-deploy monitoring

Tools:

• Ticketing: Jira, Linear, Asana
• Code review: GitHub, GitLab, Bitbucket
• CI/CD: GitHub Actions, GitLab CI, CircleCI, Jenkins
• Deployment tracking: changelog, release notes

Evidence:

• Sample van 15-20 changes: ticket, approval, review, test results, deploy logs
• Change management policy
• Emergency change procedure (for hotfixes)
• Failed change + rollback evidence (shows process works)

Veelgemaakte fout: Process exists, maar emergency changes bypass it zonder documentation. “Hotfix deployed at 3am without approval.” Oké, maar waar is emergency change policy? Als die er niet is, finding.

9. Vendor Risk Management

Wat: Third-party vendors worden geëvalueerd op security voor je ze inhuurt. Bestaande vendors worden periodiek ge-reviewed.

Implementatie:

• Vendor register: lijst van alle vendors die data/system access hebben
• Due diligence: request SOC 2, ISO 27001, of security questionnaire
• Contract reviews: security clauses, DPA’s (Data Processing Agreements)
• Annual vendor reviews: SOC 2 up to date? No breaches? Still compliant?
• Sub-processor notifications (GDPR requirement)

Tools:

• Vendor management: Vendr, Vanta, Drata (automated vendor tracking)
• Contract management: DocuSign CLM, Ironclide
• Security questionnaires: StandardizedSecurityQuestionnaires.com

Evidence:

• Vendor register (Excel: vendor name, service, data access, SOC 2 status, review date)
• Vendor SOC 2 reports (for critical vendors)
• DPA’s
• Annual review meeting notes

Critical vs non-critical vendors: Critical (must have SOC 2/ISO 27001):

• Cloud provider (AWS, Azure, GCP)
• Database hosting
• Email provider
• Authentication provider

Non-critical (security questionnaire volstaat):

• Marketing tools
• Analytics
• Non-production tools

10. Security Awareness Training

Wat: Alle medewerkers krijgen security training. Minimaal annual, bij voorkeur vaker.

Implementatie:

• New hire training (within 7-14 dagen)
• Annual refresher for all employees
• Topics: phishing, password security, data handling, incident reporting
• Phishing simulations (quarterly)
• Metrics tracked: completion rate, phishing simulation click rate

Tools:

• Training platforms: KnowBe4, Infosec IQ, Habitu8
• Phishing simulation: KnowBe4, PhishMe
• DIY: internal presentations + quiz

Evidence:

• Training completion records (naam, datum, passed quiz)
• Phishing simulation results
• Training materials (slides, videos)
• Policy: annual training requirement

Veelgemaakte fout: Training is “available” maar niet “required.” Completion rate is 60%. Auditor vraagt: waarom hebben 40% niet gedaan? Geen enforcement = finding.

Availability Controls (optioneel, maar vaak gekozen)

11. Backup en Disaster Recovery

Wat: Critical data wordt regelmatig gebackupt. Backups worden getest (restore tests). Je hebt plan voor disaster scenarios.

Implementatie: Backups:

• Automated daily backups
• Backups stored off-site (different geographic region)
• Backup encryption
• Quarterly restore tests (pick random backup, restore, verify)
• Retention: 30 days daily, 12 months weekly

Disaster Recovery:

• DR plan document: what to do if datacenter burns down
• RTO (Recovery Time Objective): binnen hoeveel tijd weer online?
• RPO (Recovery Point Objective): hoeveel data-verlies acceptabel?
• Annual DR test (simulated disaster, execute recovery)

Tools:

• Cloud-native: AWS Backup, Azure Backup
• Database-specific: RDS automated backups, MongoDB Atlas backups
• Application: Velero (Kubernetes), Restic

Evidence:

• Backup schedules configured (screenshots)
• Quarterly restore test reports
• DR plan document
• Annual DR test meeting notes + results

Veelgemaakte fout: Backups draaien, maar restore never tested. Auditor vraagt “show me last restore test.” Je hebt het niet gedaan. Finding. Untested backups = no backups.

12. Capacity Planning en Monitoring

Wat: Je monitored resource usage. Je plant voor groei. Je hebt alerting voor capacity issues.

Implementatie:

• Resource monitoring: CPU, memory, disk, network
• Threshold alerting: 80% disk = warning, 90% = critical
• Quarterly capacity reviews: trend analysis, forecasting
• Load testing before major events
• Scaling procedures (manual or auto-scaling)

Tools:

• Monitoring: Datadog, New Relic, Prometheus+Grafana
• Cloud-native: AWS CloudWatch, Azure Monitor
• Load testing: k6, Gatling, JMeter

Evidence:

• Monitoring dashboards
• Capacity review meeting notes
• Load test results
• Alerting configuration
• Scaling events (auto-scaling triggered)

13. SLA Monitoring en Reporting

Wat: Als je SLA hebt (99.9% uptime), moet je bewijzen dat je het haalt.

Implementatie:

• Uptime monitoring (external, not just internal)
• SLA reporting (monthly): actual uptime vs promised
• Downtime tracking: incidents, duration, root cause
• Status page (public or private) voor transparency

Tools:

• Uptime monitoring: Pingdom, UptimeRobot, StatusCake
• Status pages: StatusPage.io, Atlassian Statuspage
• APM: Datadog, New Relic (tracks latency, errors, apdex)

Evidence:

• Monthly SLA reports
• Downtime incident reports
• Uptime monitoring graphs (6 maanden)
• Customer communications tijdens downtime

Veelgemaakte fout: SLA is 99.9% (43 minuten downtime/maand allowable). Je had 120 minuten downtime in één maand. Dit breached SLA. Auditor ziet dit. Finding? Depends. Als het eenmalig was + documented + customer compensated, misschien oké. Als het patroon is, finding.

Confidentiality Controls (optioneel)

14. Data Classification

Wat: Data is geclassificeerd (Public, Internal, Confidential, Restricted). Behandeling is based on classification.

Implementatie:

• Data classification policy: defines levels
• Tagging/labeling van data
• Access controls based on classification
• Handling procedures per level (bijv. Confidential must be encrypted)

Tools:

• DLP (Data Loss Prevention): Symantec DLP, Microsoft Purview
• Cloud-native: AWS Macie (scans S3 for sensitive data)
• Manual: tags in databases, file naming conventions

Evidence:

• Data classification policy
• Examples of classified data
• Access controls aligned with classification
• Audit logs van access tot Confidential data

Classification example:

• Public: Website content, blog posts, public docs
• Internal: Internal wikis, non-sensitive company info
• Confidential: Customer data, contracts, financial data
• Restricted: PII, PHI, trade secrets, legal documents

15. Data Loss Prevention (DLP)

Wat: Voorkom dat confidential data onbedoeld wordt gedeeld (email, download, upload).

Implementatie:

• DLP rules in email (no emailing confidential files to external)
• DLP for file uploads (no uploading to personal Dropbox)
• USB port control (disable or monitor)
• Data exfiltration monitoring (large downloads, unusual exports)

Tools:

• Email DLP: Google Workspace DLP, Microsoft 365 DLP
• Endpoint DLP: Symantec, McAfee, Carbon Black
• Network DLP: Forcepoint, Netskope

Evidence:

• DLP policy configuration
• Alerts triggered + investigation
• Training: employees aware of DLP rules
• Exceptions (if any): documented and approved

Veelgemaakte fout: DLP is configured maar alerts worden genegeerd. Auditor ziet 50 alerts in 6 maanden. “What did you do with these?” Geen follow-up = finding.

Privacy Controls (optioneel)

16. Privacy Policy en Consent Management

Wat: Je hebt privacy policy. Users worden geïnformeerd. Consent wordt verkregen.

Implementatie:

• Privacy policy: readable, accessible, GDPR/CCPA compliant
• Cookie consent banner (strict mode: no tracking zonder consent)
• Consent records: log wie, wanneer, wat approved
• Opt-out mechanisms: easy to withdraw consent

Tools:

• Cookie consent: OneTrust, Cookiebot, Osano
• Privacy management: OneTrust, TrustArc, Securiti

Evidence:

• Privacy policy document
• Consent banner screenshots
• Consent logs
• User complaints/requests handled

17. Data Subject Rights (DSR)

Wat: Users kunnen hun data inzien, exporteren, corrigeren, verwijderen.

Implementatie:

• DSR request process: how users submit requests
• Response SLA: within 30 dagen (GDPR requirement)
• Data export tool (user can download their data)
• Deletion procedures: hard delete, not soft delete
• Verification: confirm identity before granting request

Tools:

• Privacy request management: OneTrust, TrustArc
• Data export: custom build (API endpoint)
• Deletion: automated scripts or manual process

Evidence:

• Sample DSR requests + responses
• DSR policy document
• Timelines: show requests handled within SLA
• Deletion logs (proof of deletion)

Types DSR:

• Access: “Give me copy of my data”
• Portability: “Export my data in machine-readable format”
• Rectification: “Correct my data, it’s wrong”
• Erasure: “Delete my data” (right to be forgotten)
• Objection: “Stop processing my data for X purpose”
• Restriction: “Temporarily pause processing”

Meer informatie

• Trust Services Criteria – De 5 pijlers uitgelegd
• Stappenplan – De 12 stappen naar SOC 2
• Het auditproces – Wat test de auditor
• Voor SaaS-bedrijven – Specifieke tips voor SaaS
• AICPA TSC  – Officiële criteria