SOC 2 step-by-step guide

From zero to a SOC 2 report. This step-by-step guide, based on the AICPA Trust Services Criteria , takes you through the whole process. Whether you work with Deloitte , PwC , or specialist firms such as A-LIGN .

It comes down to three things: (1) writing down how you work, (2) implementing controls, and (3) proving that they work. Already have ISO 27001? Then you have 60-80% overlap.

On this page

Below, we walk through the full SOC 2 process in 12 steps. For each step we explain: what you do, which actions you take, and which mistakes to avoid. Use this overview to jump quickly to the right step.

1. Define scope and criteria

Before you start, you need to know: what are we auditing?

Defining the scope: Which systems, which application, which infrastructure? Your first SOC 2 needs to be provable. Start small. One main application, one cloud environment. You can always expand at the next audit.

Example: You have a SaaS product on AWS. Scope: production environment, customer-facing application, AWS account. Not in scope: internal tools, development environments, your office network.

Choosing criteria: Security is mandatory. You choose the rest strategically. Ask your customers what they want to see. SaaS with an SLA? Add Availability. Sensitive data? Confidentiality. GDPR data? Privacy.

64% chooses Confidentiality, 75% Availability, 30% Processing Integrity, 20% Privacy. You do not have to choose everything.

Type I or Type II: Choose Type I if you need to remove a sales blocker quickly (3-6 months). Choose Type II if you want to show real assurance (9-15 months). Most companies start with Type I and then do Type II. Read more about the difference.

Result of this phase: A document with scope, chosen criteria, the Type I/II decision, and a timeline.

2. Gap analysis

You probably have more than you think. A gap analysis maps out what you already have and what is still missing.

Working through the checklist: Go through the AICPA Trust Services Criteria . That is roughly 60-90 control requirements, depending on the criteria you chose. For each requirement: do we have this? If so, where is it documented? If not, how will we implement it?

Technical controls: Do you have MFA? Logging? Encryption? Firewalls? Vulnerability scanning? Backup procedures? These are often already in place, but not documented.

Organisational controls: Do you have an information security policy? Access reviews? Change management? Vendor management? Incident response? This is often the biggest gap.

Using tools: Compliance platforms such as Vanta, Drata, and Secureframe can automate your gap analysis. They scan your infrastructure (AWS, Google Workspace, GitHub, and so on) and show what is missing. €5,000-€20,000 a year, but they save hundreds of hours. Read a comparison of the platforms on compliance tooling.

Result of this phase: A list of gaps, priorities, and an action plan to close them.

3. Policies and documentation

SOC 2 requires documented policies. You need to write down how you work.

Minimum required policies:

• Information Security Policy (the overarching one)
• Access Control Policy (who may access what)
• Data Classification Policy (what is confidential?)
• Change Management Policy (how do you release?)
• Incident Response Policy (what happens after a breach?)
• Vendor Management Policy (how do you select and monitor suppliers?)
• Acceptable Use Policy (what are employees allowed to do and not do?)
• Business Continuity and Disaster Recovery Policy

Not a hundred pages: A policy does not need to be a book. 2-5 pages per policy is normal. Focus on: what do we do, why, who is responsible, and how often do we review this?

Using templates is fine: Many consultants offer templates. You adapt them to your situation. Most compliance tools include built-in templates that you can customise.

ISO 27001 overlap: If you already have ISO 27001 policies, reuse them. 80% is the same. You may need to reword them to the Trust Services Criteria, but the content is largely identical.

Result of this phase: A complete set of policies, approved by management and published internally.

4. Technical controls

Now comes the IT work. The technical controls that your policies describe need to become reality.

Access management:

• Multi-Factor Authentication (MFA) on all critical systems
• Role-Based Access Control (RBAC): people get access based on their role
• Offboarding process: accounts are closed within 24 hours of departure
• Regular access reviews: check every quarter who still has access

Infrastructure security:

• Firewalls and network segmentation
• Intrusion Detection and Prevention Systems (IDS/IPS)
• DDoS protection
• VPN for remote access

Data protection:

• Encryption at rest (data on disk is encrypted)
• Encryption in transit (TLS/SSL for all connections)
• Database encryption
• Backup encryption

Logging and monitoring:

• Centralised logging (all logs collected in one system)
• Log retention (at least 90 days, often 1 year)
• Security Information and Event Management (SIEM) for alerting
• Monitoring dashboards

Vulnerability management:

• Automated vulnerability scanning (weekly)
• Patch management process (updates within X days)
• Third-party dependency scanning
• Penetration testing (annually)

Development security:

• Mandatory code reviews
• Secrets management (no passwords in code)
• Security testing in the CI/CD pipeline
• Separation of production and development environments

Most of these tools are not expensive. MFA: free or €5 per user per month. SIEM: €50-500 a month. Vulnerability scanning: €100-500 a month. Much of it is built into your cloud provider.

Result of this phase: Technical controls operational and configured according to your policies.

5. Organisational controls

The people and process side. Often harder than the technology because it requires changes in behaviour.

Security awareness training: All employees (and new hires) receive training on phishing, passwords, and data handling. At least once a year, preferably every quarter. Test with phishing simulations.

Background checks: For new employees with access to production or customer data. This does not have to be CIA-level, but you must be able to show that you do it.

Vendor risk management: Every new vendor (sub-processor) is assessed on security. Ask for their SOC 2 report, carry out due diligence, and record them in a vendor register. Review annually.

Change management: Production changes follow a process: ticket, review, approval, deployment, testing. This must be documented. Auditors pick random changes and check whether the process was followed.

Incident response: You need to show that you know what to do during a security incident. Create a playbook, assign roles, and run a test (a tabletop exercise).

Business continuity: What if AWS goes down? What if your office burns down? Create a disaster recovery plan, test your backups with restore tests, and record recovery time objectives (RTO).

Risk assessments: At least once a year: which risks do we face, how serious is the impact, and what do we do about it? Documented in a risk register.

Result of this phase: Organisational controls implemented, employees trained, processes running.

6. Evidence collection

Type II requires proof over time. You need to show that your controls worked for 3-12 months. So start collecting evidence straight away.

What to collect:

• Logs: access logs, change logs, authentication logs
• Screenshots: of configurations, dashboards, and tools
• Tickets: change requests, incident reports
• Reports: vulnerability scans, penetration tests, phishing simulations
• Meeting minutes: security reviews, risk assessments
• Training records: who was trained and when
• Sign-offs: policy approvals, access approvals

Automating where possible: Compliance tools can collect much of the evidence automatically. Daily screenshots of MFA settings, weekly vulnerability scan reports, and continuous monitoring of access changes. This saves you hundreds of hours of manual work. Read what auditors want to see for each criterion, and how to organise your evidence, on collecting evidence.

Evidence folder structure: Create a folder per control with all the evidence in it. When the auditor asks “show me that MFA was active”, you open the MFA folder with six months of daily screenshots.

Result of this phase: An evidence collection process that runs, is automated where possible, and is organised by control.

7. Observation period (Type II)

For Type II you need to prove that controls work over time. This is a waiting period of 3-12 months. Six months is the most common.

What happens: You simply do your normal work. Your controls run and evidence is collected. Every month: access reviews, vulnerability scans, backup tests, training sessions. Everything follows your policies.

Monthly checklist:

• Access review done and documented?
• Vulnerability scan run and reviewed?
• Backups tested (restore test)?
• New employees onboarded according to procedure?
• Departed employees offboarded?
• Vendor reviews done for new suppliers?
• Incidents logged and handled?
• Changes made through the change management process?

No shortcuts: You cannot shorten this period. A Type II with a 3-month observation period is possible, but most customers want to see 6 or 12 months. Check with your sales team what customers ask for.

Type I skips this step: Type I only checks the design of your controls at one point in time. No observation period is needed.

Result of this phase: 3-12 months of evidence that your controls are effective.

8. Choosing an auditor

You need an independent CPA who is allowed to carry out SOC 2 audits. Not every accountant can do this.

What to check:

• Experience with SOC 2 (how many per year?)
• Sector experience (SaaS, cloud, your industry)
• Dutch versus American firms (Dutch firms can combine ISAE 3000 and SOC 2)
• Price (varies enormously: €15,000-€80,000+)
• Timing (can they meet your schedule?)
• References (talk to other clients)

Well-known names:

• Netherlands: Deloitte, PwC, EY, KPMG (Big 4), smaller firms: Baker Tilly, Mazars, BDO
• US-oriented: A-LIGN, Schellman, Prescient Assurance, Sensiba

Requesting quotes: Get at least 3 quotes. State your scope, criteria, Type I/II, and company size clearly. Prices can vary 2-3 times between firms.

Start early: Good firms are fully booked months in advance. Start looking as soon as you have finished your gap analysis.

Result of this phase: A selected CPA firm, a signed contract, and a kick-off planned.

9. Readiness assessment

Before the official audit begins, you carry out a readiness check. This is optional but strongly recommended. Read the full explanation, including the difference from the gap analysis, doing it yourself versus outsourcing it, and concrete deliverables, on the SOC 2 readiness assessment page.

Pre-audit: Your auditor (or a consultant) carries out a mini audit. They go through your controls, check documentation, and test a few things. The goal: find what is still missing before the real audit begins.

What comes out of it: A list of findings: policies that do not match reality, missing documentation, controls that are not complete. You still have time to fix them.

Why do this: Nothing is worse than discovering halfway through the official audit that you have major gaps. Findings in the readiness assessment are not a problem. Findings in the official audit end up in your report.

Costs: €2,000-€8,000 for a readiness assessment. It pays for itself immediately in confidence and in avoiding findings.

Result of this phase: A readiness report with action points, and everything fixed before the audit begins.

10. Official audit

Now the real work begins. The auditor comes in to examine your organisation.

Planning meeting: Kick-off with the auditor. You go through your scope, criteria, and systems, and give a tour. The auditor explains what they will do and what they need.

Document request: You receive a long list: policies, procedures, evidence, screenshots, logs, reports. Everything you collected in step 6. Deliver it organised.

Fieldwork: The auditor tests your controls. They ask: “Show me that MFA is active.” You show screenshots, and they log in themselves to verify. “Show me an access review.” You show meeting minutes and approval emails.

Sampling: For Type II, the auditor picks random samples across the observation period. “Show me 3 changes from May and 2 from July.” They check whether your change management process was really followed.

Interviews: Conversations with key personnel. The CTO about architecture, the security lead about incident response, HR about onboarding and offboarding. The auditor tests whether people know what the policies say.

Testing: Technical tests. The auditor tries to log in without MFA (it must fail), checks firewall rules, reviews encryption settings, and checks the logging configuration.

Findings: If something is not right, you receive a finding. It goes into your report. You have time to remediate, but the finding stays unless you have a re-audit.

Duration: 5-12 weeks for the fieldwork, depending on complexity and how well your evidence is organised.

Result of this phase: Audit completed, all controls tested, findings identified.

11. Draft report and response

You receive a draft report. Now it is time to review it.

What it contains:

• Scope and criteria
• Description of your systems and controls
• Test results
• Findings (if any)
• The auditor’s opinion

Types of findings:

• Control deficiency: The control exists, but does not work properly
• Significant deficiency: Several deficiencies or a serious weakness
• Material weakness: A major error with potentially serious impact

Management response: For each finding, you write a response: what went wrong, what we have done, and when it will be resolved. This goes into the report.

Review carefully: Check that all facts are correct. Are the descriptions accurate? Is the scope correct? Are there no errors in how your systems are described?

No findings means a clean report: If everything is in order, you receive an unqualified opinion: “controls are effectively designed and operating effectively.” This is what customers want to see.

Result of this phase: A final report, ready to share.

12. Receiving the report

You have your SOC 2 report. What now?

Formats: You receive a PDF, often 50-150 pages. It contains sensitive information about your infrastructure, so it is confidential.

How to share it:

• Through secure portals (not email attachments)
• An NDA is required for recipients
• Limited distribution: only relevant customers and prospects
• Redacted version: sometimes you create a version without sensitive details

Using it in sales:

• RFPs: attach it in the security section
• Due diligence: share it during procurement
• Website: a “SOC 2 compliant” badge (but do not publish the full report publicly)
• Security questionnaires: many questions are answered with “see SOC 2 report”

SOC 3 option: A public, shortened version of SOC 2. Less detail, but it can be shared freely. Ask your auditor whether this is available.

Validity: The report covers the observation period. After 12 months your customers will want a new report. So plan your re-audit right away.

Result of this phase: A SOC 2 report in production, sales unblocked, customers satisfied.

After attestation: the work continues

SOC 2 is not a one-off project. It is continuous compliance.

Maintenance: Your controls need to keep running. Access reviews every quarter, vulnerability scans weekly, training annually. If you stop, the controls stop working and you will fail the next audit.

Re-audit cycle: Repeat every year. The good news: a re-audit takes 50-70% of the effort of the first time. You already have policies, controls are running, and you know how it works.

Continuous monitoring: Modern compliance happens in real time. Tools monitor your controls every day. An alert when MFA is switched off, when a privileged user is added, or when a change goes outside the process.

Expanding scope: First SOC 2: small and secure. Following years: add more criteria, more systems in scope, move from Type I to Type II.

Common mistakes with SOC 2

Starting too late You have 3 months until a deadline. Type II takes 9+ months. That deadline will not be met. Start early.

Collecting evidence only afterwards You have six months of observation behind you with no evidence. You cannot go back in time. Start on day 1.

Policies that do not match reality Your policy says: “passwords 12 characters.” Your system enforces 8. The auditor tests this. Finding. Make sure policy and practice match.

Not testing controls You have backups, but never test whether a restore works. During the audit, the restore fails. Major finding. Test your controls regularly.

Forgetting vendor management You use 20 sub-processors without due diligence. The auditor asks: “Where is their SOC 2?” You never asked. Finding.

Thinking tooling is enough Platforms help a great deal, but they are not the solution. You still have to do the work: write policies, train people, review evidence.

Timeline visualisation

Typical timeline for a medium-sized SaaS company (first Type II):

Total: 14 months from start to report for a first Type II. Type I: 4-6 months.

More information

• Costs and timeline: Detailed breakdown of costs
• Trust Services Criteria: The 5 criteria explained
• The audit process: What exactly the auditor does
• Frequently asked questions: All questions answered
• SOC 2 vs ISO 27001: When do you choose which?

Sources

• AICPA Trust Services Criteria : Official criteria from the AICPA
• AICPA SOC 2 Guidance : Official AICPA page on SOC 2
• NOREA , the Dutch professional body for IT auditors
• ISAE 3000 : International auditing standard (IFAC)