Het SOC 2 auditproces

Stap 1: Planning en kickoff (Week 1-2)

De audit start formeel, maar je bent al maanden aan het voorbereiden.

Kickoff meeting: Je, je team (CTO, security lead, compliance PM), en de auditor. Agenda:

• Scope bevestigen: welke systemen, welke Trust Services Criteria, welke periode
• Tijdlijn afspreken: welke weken, wie is beschikbaar, deadlines
• Document request list: auditor geeft lijst van wat hij wil zien
• Tour: je laat je systems zien, architecture, hoe je werkt
• Q&A: vragen over je business, tech stack, team

Document request: Je krijgt een Excel met 50-200 items:

• Policies en procedures (alle)
• Network diagrams
• Access control matrices (wie heeft toegang tot wat)
• Risk assessments
• Vendor lijst met hun SOC 2 rapporten
• Evidence per control (logs, screenshots, reports)
• HR documentation (onboarding, offboarding, training records)
• Change management logs
• Incident reports (als die er waren)
• Backup test resultaten
• Penetration test rapport

Voorbereiding: Je hebt ideaal al alles georganiseerd in een folder structuur:

SOC2-Evidence/
├── Policies/
├── Risk-Assessments/
├── Vendor-Management/
├── Access-Controls/
│   ├── Q1-access-review/
│   ├── Q2-access-review/
│   ├── Onboarding-evidence/
│   └── Offboarding-evidence/
├── Vulnerability-Management/
├── Change-Management/
├── Incident-Response/
├── Backups-and-DR/
└── Training/

Upload alles naar secure portal (auditor geeft je toegang tot hun systeem).

Resultaat van deze fase: Kickoff gedaan, document request ontvangen, evidence geupload, timeline agreed.

Stap 2: Documentation review (Week 2-4)

Auditor leest al je documenten. Hij kijkt of:

• Policies zijn compleet, logisch, en volgen best practices
• Procedures zijn gedocumenteerd (hoe doe je dingen)
• Risk assessments zijn recent en thorough
• Vendors zijn geëvalueerd op security
• Evidence is georganiseerd en complete

Wat hij checkt:

Policies:

• Information Security Policy complete?
• Access Control Policy: covers MFA, RBAC, least privilege?
• Change Management Policy: alle changes via proces?
• Incident Response Policy: wie doet wat, tijdlijnen?
• Vendor Management Policy: hoe selecteer/review je vendors?
• Backup and DR Policy: RPO/RTO defined?

Coherentie: Hij checkt of policies bij elkaar passen. Als je Access Control policy zegt “passwords 12 characters” maar je Acceptable Use policy zegt “8 characters,” is dat een finding.

Actualiteit: Policies moeten recent zijn (binnen 12 maanden reviewed). Als je policy zegt “reviewed June 2023” en het is nu January 2026, is dat een finding. Je moet annual review doen.

Preliminary questions: Je krijgt 20-50 vragen via email:

• “Explain how you manage encryption keys”
• “Who has admin access to AWS production?”
• “How do you handle employee termination?”
• “What monitoring tools do you use?”

Dit zijn clarifying questions. Geen tricks, hij wil gewoon dingen begrijpen.

Resultaat van deze fase: Auditor heeft alle documenten gelezen, preliminary questions beantwoord, hij weet hoe je systemen werken.

Stap 3: Control testing (Week 4-8)

Nu gaat de auditor testen of je controls echt werken.

Access control testing:

“Laat zien dat MFA actief is.” Je laat screenshots zien van AWS Console settings, GitHub org settings, Google Workspace admin panel. Auditor logt zelf in (test account) om te verifiëren.

“Laat zien dat access reviews gebeuren.” Je laat meeting minutes zien van quarterly access reviews. Attendees: CTO, security lead. Datum. Agenda: “Review all AWS users, GitHub access, production database access.” Resultaat: “3 users offboarded, 2 permissions downgraded.”

“Laat zien dat onboarding correct gaat.” Auditor kiest 5 nieuwe medewerkers (random sampling). Voor elk:

• HR form met start datum
• IT ticket voor account setup
• Evidence van background check
• Security awareness training completion
• NDA signed
• Access granted via approval process

Hij checkt tijdlijnen: was training binnen 7 dagen? Was account setup volgens policy?

Network security testing:

“Laat zien dat firewalls correct zijn geconfigureerd.” Screenshots van AWS Security Groups, firewall rules. Auditor checkt: geen 0.0.0.0/0 open voor production, alleen whitelisted IPs voor sensitive services.

“Laat zien dat production gescheiden is van development.” Network diagram showing VPCs, subnets. Auditor verifiëert: geen direct connectivity tussen dev en prod.

Vulnerability management testing:

“Laat zien dat vulnerability scans wekelijks gebeuren.” Je laat 26 reports zien (weekly over 6 maanden). Auditor kiest random 3 weeks, bekijkt reports. Checkt:

• Scans hebben gerund
• Vulnerabilities zijn gevonden
• Critical/high zijn opgelost binnen SLA (bijv. 30 dagen)
• Resolution is gedocumenteerd

“Laat zien dat penetration testing jaarlijks gebeurt.” Pentest rapport van external firm. Datum: binnen 12 maanden. Auditor leest findings. Checkt: zijn alle findings addressed? Als niet, waarom niet (risk acceptance documented)?

Change management testing (Type II specific):

Auditor kiest 15-20 changes random uit je observatieperiode. Per change checkt hij:

• Was er een ticket? (Jira, GitHub issue, etc.)
• Was er approval? (van wie, wanneer)
• Was er peer review? (code review for software changes)
• Was er testing? (test results documented)
• Was er communicatie? (stakeholders informed)

Als één change buiten het proces ging, is dat een finding. “On July 15, hotfix deployed without approval.” Waarom? “System was down, emergency.” Oké, maar waar is emergency change procedure? Als die er niet is, finding.

Sampling sizes: Auditor gebruikt statistical sampling:

• Population < 10: test alles
• Population 10-50: test 10
• Population 50-100: test 15
• Population 100+: test 20-25

Dit is gebaseerd op audit standards. Hij kan niet alles testen, maar wel genoeg voor statistical confidence.

Testing methods:

• Inquiry: Vragen stellen aan je team
• Observation: Auditor ziet je processes in actie
• Inspection: Bekijkt documentatie en evidence
• Reperformance: Auditor doet het zelf (bijv. probeert in te loggen zonder MFA)

Resultaat van deze fase: Alle controls zijn getest via sampling, auditor heeft lijst van findings (als die er zijn).

Stap 4: Interviews met key personnel (Week 5-7)

Auditor wil met mensen praten. Niet om te “caughten” maar om te verifiëren dat mensen weten wat de policies zijn en hoe processen werken.

Wie wordt geïnterviewd:

• CTO / VP Engineering: architecture, security beslissingen
• Security lead: wie doet wat, tooling, incident response
• DevOps/SRE: change management, backups, monitoring
• HR: onboarding, offboarding, background checks
• Compliance/GRC lead: policies, risk assessments, audits

Typische vragen:

Aan CTO:

• “Explain your architecture. Where is customer data stored?”
• “How do you make security decisions? (risk-based? compliance-driven?)”
• “What happens if AWS us-east-1 goes down?”

Aan security lead:

• “Walk me through your incident response process.”
• “How do you manage vulnerability remediation?”
• “Who can access production? How is that access granted?”

Aan DevOps:

• “Show me how you deploy a change to production.”
• “How do you test backups?”
• “What monitoring alerts do you have?”

Aan HR:

• “What happens when someone joins the team?”
• “What happens when someone leaves?”
• “How do you verify background checks?”

Wat auditor checkt: Consistency. Als je policy zegt “changes need CTO approval” en DevOps engineer zegt “we merge PRs with 1 LGTM from any senior,” is er mismatch. Either policy is outdated or process is not followed. Dat is een finding.

Tips voor interviews:

• Wees eerlijk. “I don’t know” is beter dan bullshit.
• Don’t over-promise. “We’ll implement that next quarter” ≠ “we have that.”
• Refer to documentation. “Let me show you our runbook.”
• Stay calm. Dit is geen interrogation, het is verificatie.

Resultaat van deze fase: Auditor heeft helder beeld van wie wat doet en of mensen weten hoe processen werken.

Stap 5: Technical testing (Week 6-8)

Auditor doet hands-on technical tests. Hij wil niet alleen dat je zegt “we hebben firewalls,” hij wil ze zien werken.

Configuratie checks:

MFA: Auditor probeert in te loggen in AWS Console zonder MFA. Moet falen. Probeert in te loggen met MFA. Moet lukken. Hij checkt: is MFA enforced op org-level? Kunnen users het uitzetten? (moet nee zijn)

Encryption: Auditor checkt S3 buckets: is default encryption aan? Checkt RDS databases: is encryption at rest enabled? Checkt ALB/CloudFront: TLS 1.2+ enforced?

Access controls: Auditor krijgt test account zonder production access. Probeert production database te benaderen. Moet falen. Probeert via bastion host (als dat het proces is). Moet logged worden.

Logging: Auditor doet test action (bijv. login, API call). Checkt of dit gelogd is in je SIEM. Timestamp, user, action, result.

System scans:

Auditor runt eigen tools:

• Network scan (open ports? unexpected services?)
• SSL/TLS scan (zwakke ciphers? expired certificates?)
• DNS enumeration (exposed internal services?)

Dit is niet om je te hacken, maar om te verifiëren dat je external footprint minimaal is.

Review van third-party tools:

Auditor checkt je monitoring/security tooling:

• SIEM: is het actief? Zijn er alerts? Worden ze reviewed?
• Vulnerability scanner: recente scans? Findings opgevolgd?
• Backup solution: automated? Tested? Off-site?
• IDS/IPS: deployed? Tuned? Alerts actionable?

Resultaat van deze fase: Technical testing compleet, auditor weet dat controls niet alleen op papier staan maar echt werken.

Stap 6: Findings review en management response (Week 9-10)

Auditor heeft alle testing gedaan. Hij compileert findings (als die er zijn).

Types findings:

Control deficiency: Eén control werkte niet zoals bedoeld. Voorbeeld: “On August 3, an employee was offboarded but AWS account was not disabled until August 6 (3 days later). Policy states 24 hours.”

Significant deficiency: Meerdere deficiencies of ernstiger probleem. Voorbeeld: “Quarterly access reviews were not performed in Q2 2025. This was identified and Q3/Q4 reviews were completed.”

Material weakness: Groot probleem met potentieel zware impact. Voorbeeld: “Production database backup restoration has not been tested in 18 months. During audit, test restore failed. Backup process was not effective.”

Draft findings meeting: Auditor deelt draft findings. Je discussieert:

• Is de finding correct? (soms misverstand, je laat extra evidence zien)
• Wat is de severity? (je kunt argumenteren voor downgrade)
• Wat heb je al gedaan? (remediatie vóór audit eindigt)

Management response: Per finding schrijf je een response:

• Description: Wat ging er mis
• Root cause: Waarom gebeurde dit
• Remediation: Wat hebben we gedaan
• Timeline: Wanneer was het opgelost
• Prevention: Hoe voorkom we herhaling

Voorbeeld management response:

Finding: Access review for Q2 2025 was not performed as required by policy.

Management Response: This was due to competing priorities during a product launch. We acknowledge this was a lapse. Immediately upon discovery (July 15), we:

1. Performed a comprehensive access review for Q2 retroactively (completed July 20)
2. Set up quarterly recurring calendar reminders for the Security Lead with 2-week advance notice
3. Added access review status to monthly management reporting
4. Q3 and Q4 2025 reviews were performed on schedule (evidence provided)

Preventive measures: Access reviews are now a standing agenda item in monthly security meetings, ensuring visibility and accountability.

Dit komt in je rapport. Clean management response toont dat je mature bent en het serieus neemt.

Resultaat van deze fase: Alle findings zijn besproken, management responses geschreven, remediatie gedocumenteerd.

Stap 7: Draft rapport en review (Week 11-12)

Je krijgt draft SOC 2 rapport. Dit is 50-150 pagina’s.

Wat erin staat:

Section 1: Independent Service Auditor’s Report De auditor’s opinion. Types:

• Unqualified (clean): “Controls waren effectief ontworpen en werkten effectief” → best case
• Qualified: “Controls waren effectief behalve voor…” → findings erbij vermeld
• Adverse: “Controls waren niet effectief” → zeer zeldzaam, grote problemen

Section 2: Management’s Assertion Jouw statement: “We declare dat our controls were suitably designed and operating effectively.” Dit is jouw responsibility, niet de auditor’s. Hij test of jouw assertion klopt.

Section 3: Description of the System

• Company overview
• Services provided
• Infrastructure (cloud providers, data centers)
• Software used (programming languages, frameworks, databases)
• Boundaries: wat is in scope, wat niet
• Trust Services Criteria used (Security, Availability, etc.)

Dit is publiekelijk shareable deel (zonder findings). Sommige bedrijven redacten sensitive details (specifieke IPs, internal tool names).

Section 4: Trust Services Criteria, Control Activities, and Tests De bulk. Voor elke criteria:

• Control objectives
• Control activities (wat je doet)
• Tests performed (wat auditor testte)
• Results (pass/fail/finding)

Per control:

• Description: “Company enforces MFA on all cloud admin accounts”
• Test: “Inspected AWS IAM settings and verified MFA policy. Attempted login without MFA (failed as expected). Tested with MFA (succeeded).”
• Result: “No exceptions noted” OF “See finding [X]”

Section 5: Complementary User Entity Controls (CUECs) Dit zijn controls die jouw klanten moeten doen. Bijvoorbeeld:

• “Customers are responsible for managing user access within the application”
• “Customers must maintain secure credentials and not share passwords”
• “Customers should monitor their usage logs for suspicious activity”

Dit is om duidelijk te maken: jullie hebben verantwoordelijkheden ook. Wij zijn secure, maar als jullie wachtwoord “password123” is, is dat jullie probleem.

Section 6: Other Information Findings en management responses. Als je clean rapport hebt, is deze sectie leeg of zeer kort.

Review proces:

Je leest draft grondig. Check:

• Zijn alle feiten correct?
• Is je system description accuraat?
• Zijn findings fair vermeld?
• Zijn management responses volledig opgenomen?
• Zijn er redactable details? (proprietary info, specific IPs, vendor names je niet publiek wil)

Feedback ronde: Je geeft comments. Auditor addresseert. Soms zijn er 2-3 draft versies voordat final.

Resultaat van deze fase: Final rapport klaar, akkoord van beide partijen.