The SOC 2 audit process

Step 1: Planning and kickoff (Weeks 1-2)

The audit starts formally, but you have already been preparing for months.

Kickoff meeting: You, your team (CTO, security lead, compliance PM) and the auditor. Agenda:

• Confirm scope: which systems, which Trust Services Criteria, which period
• Agree the timeline: which weeks, who is available, deadlines
• Document request list: the auditor provides a list of what they want to see
• Tour: you show your systems, architecture and how you work
• Q&A: questions about your business, tech stack and team

Document request: You receive an Excel file with 50-200 items:

• Policies and procedures (all of them)
• Network diagrams
• Access control matrices (who has access to what)
• Risk assessments
• Vendor list with their SOC 2 reports
• Evidence per control (logs, screenshots, reports)
• HR documentation (onboarding, offboarding, training records)
• Change management logs
• Incident reports (if there were any)
• Backup test results
• Penetration test report

Preparation: Ideally, you have already organised everything in a folder structure:

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 everything to the secure portal (the auditor gives you access to their system).

Result of this phase: Kickoff done, document request received, evidence uploaded, timeline agreed.

Step 2: Documentation review (Weeks 2-4)

The auditor reads all your documents. They check whether:

• Policies are complete, logical and follow best practice
• Procedures are documented (how you do things)
• Risk assessments are recent and thorough
• Vendors have been assessed for security
• Evidence is organised and complete

What they check:

Policies:

• Is the Information Security Policy complete?
• Does the Access Control Policy cover MFA, RBAC and least privilege?
• Do all changes follow the change management process?
• Does the Incident Response Policy say who does what, and by when?
• How do you select and review vendors, according to the Vendor Management Policy?
• Are RPO and RTO defined in the Backup and DR Policy?

Consistency: The auditor checks whether the policies fit together. If your Access Control policy says “passwords must be 12 characters” but your Acceptable Use policy says “8 characters,” that is a finding.

Currency: Policies must be recent (reviewed within the last 12 months). If your policy says “reviewed June 2023” and it is now January 2026, that is a finding. You must carry out an annual review.

Preliminary questions: You receive 20-50 questions by 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?”

These are clarifying questions. No tricks. The auditor simply wants to understand things.

Result of this phase: The auditor has read all documents, received answers to the preliminary questions and understands how your systems work.

Step 3: Control testing (Weeks 4-8)

Now the auditor tests whether your controls really work.

Access control testing:

“Show that MFA is active.” You show screenshots of the AWS Console settings, GitHub org settings and the Google Workspace admin panel. The auditor logs in themselves (with a test account) to verify.

“Show that access reviews take place.” You show the meeting minutes of the quarterly access reviews. Attendees: CTO and security lead. Date. Agenda: “Review all AWS users, GitHub access, production database access.” Result: “3 users offboarded, 2 permissions downgraded.”

“Show that onboarding works correctly.” The auditor picks 5 new employees (random sampling). For each one:

• HR form with start date
• IT ticket for account setup
• Evidence of a background check
• Security awareness training completion
• NDA signed
• Access granted through the approval process

They check the timelines: was training completed within 7 days? Was the account set up according to policy?

Network security testing:

“Show that firewalls are configured correctly.” Screenshots of AWS Security Groups and firewall rules. The auditor checks: no 0.0.0.0/0 open for production, and only whitelisted IPs for sensitive services.

“Show that production is separate from development.” Network diagram showing VPCs and subnets. The auditor verifies there is no direct connectivity between dev and prod.

Vulnerability management testing:

“Show that vulnerability scans run every week.” You show 26 reports (weekly over six months). The auditor picks 3 weeks at random and reviews the reports. They check:

• Scans have run
• Vulnerabilities were found
• Critical and high findings were fixed within the SLA (for example 30 days)
• The resolution is documented

“Show that penetration testing happens every year.” Penetration test report from an external firm. Date: within 12 months. The auditor reads the findings and checks: have all findings been addressed? If not, why not (is the risk acceptance documented)?

Change management testing (Type II specific):

The auditor picks 15-20 changes at random from your observation period. For each change they check:

• Was there a ticket? (Jira, GitHub issue, etc.)
• Was there approval? (from whom, and when)
• Was there peer review? (code review for software changes)
• Was there testing? (test results documented)
• Was there communication? (stakeholders informed)

If one change went outside the process, that is a finding. For example: “On July 15, hotfix deployed without approval.” Why? “System was down, emergency.” Fine, but where is the emergency change procedure? If it does not exist, that is a finding.

Sample sizes: The auditor uses statistical sampling:

• Population under 10: test everything
• Population 10-50: test 10
• Population 50-100: test 15
• Population 100 or more: test 20-25

This is based on audit standards. The auditor cannot test everything, but tests enough to reach statistical confidence.

Testing methods:

• Inquiry: Asking your team questions
• Observation: The auditor watches your processes in action
• Inspection: Reviewing documentation and evidence
• Reperformance: The auditor does it themselves (for example, tries to log in without MFA)

Result of this phase: All controls have been tested through sampling, and the auditor has a list of findings (if there are any).

Step 4: Interviews with key personnel (Weeks 5-7)

The auditor wants to talk to people. Not to “catch” anyone, but to verify that people know what the policies say and how processes work.

Who gets interviewed:

• CTO / VP Engineering: architecture and security decisions
• Security lead: who does what, tooling, incident response
• DevOps/SRE: change management, backups, monitoring
• HR: onboarding, offboarding, background checks
• Compliance/GRC lead: policies, risk assessments, audits

Typical questions:

To the 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?”

To the security lead:

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

To DevOps:

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

To HR:

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

What the auditor checks: Consistency. If your policy says “changes need CTO approval” and a DevOps engineer says “we merge PRs with one LGTM from any senior,” there is a mismatch. Either the policy is outdated or the process is not followed. That is a finding.

Tips for interviews:

• Be honest. “I don’t know” is better than making something up.
• Do not over-promise. “We’ll implement that next quarter” is not the same as “we have that.”
• Refer to documentation. “Let me show you our runbook.”
• Stay calm. This is not an interrogation. It is verification.

Result of this phase: The auditor has a clear picture of who does what, and whether people know how processes work.

Step 5: Technical testing (Weeks 6-8)

The auditor carries out hands-on technical tests. They do not just want you to say “we have firewalls.” They want to see them working.

Configuration checks:

MFA: The auditor tries to log in to the AWS Console without MFA. It must fail. They try to log in with MFA. It must succeed. They check: is MFA enforced at organisation level? Can users switch it off? (It must be no.)

Encryption: The auditor checks S3 buckets: is default encryption on? They check RDS databases: is encryption at rest enabled? They check ALB and CloudFront: is TLS 1.2 or higher enforced?

Access controls: The auditor receives a test account without production access. They try to reach the production database. It must fail. They try via the bastion host (if that is the process). The attempt must be logged.

Logging: The auditor performs a test action (for example a login or an API call). They check whether it was logged in your SIEM. Timestamp, user, action and result.

System scans:

The auditor runs their own tools:

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

This is not to hack you. It verifies that your external footprint is minimal.

Review of third-party tools:

The auditor checks your monitoring and security tooling:

• SIEM: is it active? Are there alerts? Are they reviewed?
• Vulnerability scanner: recent scans? Are findings followed up?
• Backup solution: automated? Tested? Off-site?
• IDS/IPS: deployed? Tuned? Are alerts actionable?

Result of this phase: Technical testing is complete, and the auditor knows the controls are not just on paper but really work.

Step 6: Findings review and management response (Weeks 9-10)

The auditor has completed all testing. They compile the findings (if there are any).

Types of findings:

Control deficiency: One control did not work as intended. Example: “On August 3, an employee was offboarded, but the AWS account was not disabled until August 6 (3 days later). Policy states 24 hours.”

Significant deficiency: Several deficiencies, or a more serious problem. Example: “Quarterly access reviews were not performed in Q2 2025. This was identified, and the Q3 and Q4 reviews were completed.”

Material weakness: A major problem with potentially serious impact. Example: “Production database backup restoration has not been tested in 18 months. During the audit, the test restore failed. The backup process was not effective.”

Draft findings meeting: The auditor shares the draft findings. You discuss:

• Is the finding correct? (sometimes there is a misunderstanding, and you show extra evidence)
• What is the severity? (you can argue for a downgrade)
• What have you already done? (remediation before the audit ends)

Management response: For each finding you write a response:

• Description: What went wrong
• Root cause: Why it happened
• Remediation: What we did
• Timeline: When it was resolved
• Prevention: How we prevent it from happening again

Example 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.

This goes into your report. A clear management response shows that you respond maturely and take the matter seriously.

Result of this phase: All findings have been discussed, management responses written and remediation documented.

Step 7: Draft report and review (Weeks 11-12)

You receive the draft SOC 2 report. It runs to 50-150 pages.

What is in it:

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

• Unqualified (clean): “Controls were suitably designed and operated effectively.” The best case.
• Qualified: “Controls were effective, except for…” The findings are listed.
• Adverse: “Controls were not effective.” Very rare, and a sign of major problems.

Section 2: Management’s Assertion Your statement: “We declare that our controls were suitably designed and operating effectively.” This is your responsibility, not the auditor’s. The auditor tests whether your statement holds.

Section 3: Description of the System

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

This is the part that can be shared publicly (without findings). Some companies redact sensitive details, such as specific IP addresses or internal tool names.

Section 4: Trust Services Criteria, Control Activities, and Tests The bulk of the report. For each criterion:

• Control objectives
• Control activities (what you do)
• Tests performed (what the auditor tested)
• Results (pass, fail or finding)

For each control:

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

Section 5: Complementary User Entity Controls (CUECs) These are controls your customers must perform. For example:

• “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”

This makes clear that you have responsibilities too. You are secure, but if your customer’s password is “password123,” that is their problem.

Section 6: Other Information Findings and management responses. If you have a clean report, this section is empty or very short.

Review process:

Read the draft carefully. Check:

• Are all facts correct?
• Is your system description accurate?
• Are the findings stated fairly?
• Are the management responses included in full?
• Are there details to redact? (proprietary information, specific IP addresses, vendor names you do not want to make public)

Feedback round: You provide comments. The auditor addresses them. There are sometimes two or three draft versions before the final one.

Result of this phase: The final report is ready and agreed by both parties.