SOC 2 Readiness for SaaS Companies: Scope, Controls and Audit Preparation

In this article

1. Why Does SOC 2 Readiness Matter for SaaS Companies?
2. What Does SOC 2 Help Demonstrate?
3. Why European SaaS Companies Consider SOC 2
4. How Does SOC 2 Relate to EU Regulation?
5. Understanding the SOC 2 Framework and Trust Services Criteria
6. 1. Security
7. 2. Availability
8. 3. Processing Integrity
9. 4. Confidentiality
10. 5. Privacy
11. How should a SaaS company select its Trust Services Criteria?
12. What Is Changing in the Trust Services Criteria?
13. SOC 2 Type 1 vs Type 2: Which Report Should You Prepare For?
14. SOC 2 Type 1
15. SOC 2 Type 2
16. How Should You Choose?
17. SOC 2 vs ISO 27001: How Do They Compare?
18. How to Define Your SOC 2 Audit Scope
19. 1. Identify the Service Being Examined
20. 2. Map the System Boundaries
21. 3. Identify Third-Party Dependencies
22. 4. Document Scope Exclusions
23. How to Assess SOC 2 Controls and Assign Ownership
24. Identify Existing Controls
25. Map Controls to Relevant Criteria
26. Assign Control Owners
27. SOC 2 Evidence Collection and Documentation
28. Common SOC 2 Evidence Examples
29. What Makes Evidence Useful?
30. How to Prepare for a SOC 2 Audit
31. Step 1: Conduct a Readiness Assessment
32. Step 2: Prioritise Control Gaps
33. Step 3: Implement and Test Controls
34. Step 4: Organise Audit Documentation
35. Step 5: Conduct an Internal Review
36. Step 6: Coordinate With the CPA Firm
37. Common SOC 2 Readiness Mistakes
38. 1. Starting Without a Defined Scope
39. 2. Treating Policies as Proof of Implementation
40. 3. Assigning Controls Without Clear Ownership
41. 4. Collecting Evidence Only Before the Audit
42. 5. Assuming ISO 27001 Automatically Covers SOC 2
43. How SOC 2 Compliance Software Supports Readiness
44. How AnnexOps Supports SOC 2 Readiness
45. Build a Structured SOC 2 Readiness Process With AnnexOps
46. Related Reading
47. Build a Structured SOC 2 Readiness Process With AnnexOps
48. Author: Nitin Grover

Enterprise customers increasingly expect SaaS providers to demonstrate how they protect customer information, manage system access, monitor security events and maintain service availability. For companies selling software to international businesses, these questions can influence procurement decisions and customer trust.

A SOC 2 report provides independent assurance about controls at a service organisation. It is an attestation report, not a certification: a licensed, independent CPA firm examines the controls under the AICPA attestation standards and issues a report with an opinion. The controls are evaluated against the applicable AICPA Trust Services Criteria (TSC), covering Security, Availability, Processing Integrity, Confidentiality and Privacy.

However, preparing for SOC 2 involves more than writing security policies or collecting screenshots. SaaS companies need to define the system under examination, select relevant Trust Services Criteria, assign control owners and demonstrate that controls are appropriately designed and operating.

A structured SOC 2 readiness process helps organisations identify gaps before an independent CPA examination begins. It also gives engineering, security, compliance and management teams a shared understanding of their responsibilities.

SOC 2 is particularly relevant to European SaaS companies serving international enterprise customers. It can complement existing information security practices and customer assurance processes, although it does not replace GDPR obligations or ISO 27001 certification.

This guide explains how SaaS companies can prepare for SOC 2, define their audit scope, implement relevant controls, organise evidence and coordinate audit activities.

For more detailed guidance, explore these related resources:

• SOC 2 Evidence Collection: What Auditors Expect from SaaS Companies
• SOC 2 Vendor Risk Management: How to Assess and Monitor Third-Party Providers
• SOC 2 Access Controls: Managing User Access, Reviews and Audit Evidence

SaaS companies preparing for enterprise security reviews often need to coordinate SOC 2 with existing ISO 27001, GDPR and other governance activities. A structured approach can help teams reuse relevant processes without assuming that one framework automatically satisfies another.

Why Does SOC 2 Readiness Matter for SaaS Companies?

SaaS providers often process business-critical information, host customer applications and maintain integrations with external services. Customers need confidence that these systems are supported by appropriate security and operational controls.

During enterprise procurement, prospective customers may ask about access management, encryption, incident response, backup procedures, vendor oversight and change management. They may also request independent assurance before signing a contract.

A SOC 2 report can help address these questions by providing information about the service organisation’s system and an independent CPA’s examination of relevant controls. SOC 2 reports are intended for specified parties, such as customers and prospects, and are usually shared under confidentiality terms. A SOC 3 report is a separate, general-use summary.

What Does SOC 2 Help Demonstrate?

SOC 2 readiness helps an organisation prepare to demonstrate that its controls address relevant Trust Services Criteria.

For SaaS businesses, this may include:

• Information security: How the organisation protects systems and information against unauthorised access.
• System availability: How it manages service availability, capacity and recovery commitments.
• Confidentiality: How it protects information designated as confidential.
• Processing integrity: How it ensures system processing is complete, valid, accurate, timely and authorised.
• Privacy: How it handles personal information in accordance with its stated privacy commitments and applicable criteria.

The Security category is the common foundation of a SOC 2 examination. The other categories are included when relevant to the service commitments and business requirements being examined.

Why European SaaS Companies Consider SOC 2

SOC 2 is based on AICPA attestation standards rather than European legislation. Nevertheless, European SaaS businesses may pursue it when:

• Selling to US-based enterprise customers.
• Responding to international procurement requirements.
• Demonstrating security practices to business partners.
• Strengthening customer assurance processes.
• Supporting a broader information security programme.

For European organisations, SOC 2 should be considered alongside applicable obligations such as GDPR and contractual security requirements. A SOC 2 report does not automatically demonstrate GDPR compliance.

How Does SOC 2 Relate to EU Regulation?

SOC 2 is not a European legal requirement, but European rules shape what your customers ask for.

• GDPR: Customers that use you as a processor must make sure you provide appropriate security (Articles 28 and 32). A SOC 2 report can be one piece of evidence. It is not a certification mechanism under Article 42 of the GDPR, and it does not show GDPR compliance on its own.
• NIS2: Entities in scope of Directive (EU) 2022/2555 must manage cybersecurity risk, including in their supply chain (Article 21). Expect security questionnaires from these customers.
• DORA: Financial entities under Regulation (EU) 2022/2554 must manage ICT third-party risk (Article 28), and may ask you for assurance and contract terms.

In each case a SOC 2 report supports the conversation. It does not make you compliant with the regulation your customer is subject to.

Understanding the SOC 2 Framework and Trust Services Criteria

The SOC 2 framework uses the AICPA Trust Services Criteria to evaluate controls relevant to a service organisation’s systems. The current criteria contain 61 criteria across the five categories.

The five Trust Services categories are Security, Availability, Processing Integrity, Confidentiality and Privacy.

1. Security

Security is the required foundation of SOC 2. It addresses whether systems are protected against unauthorised access, unauthorised disclosure and damage that could compromise the organisation’s ability to meet its objectives.

The Common Criteria, identified as CC1 to CC9, cover areas such as:

• Control environment and organisational responsibilities (CC1).
• Communication and information (CC2).
• Risk assessment (CC3).
• Monitoring activities (CC4).
• Control activities (CC5).
• Logical and physical access (CC6).
• System operations (CC7).
• Change management (CC8).
• Risk mitigation, including vendor oversight (CC9).

2. Availability

Availability focuses on whether systems are available and usable according to the organisation’s commitments.

Relevant practices may include capacity monitoring, backup management, disaster recovery planning and incident response.

3. Processing Integrity

Processing Integrity addresses whether system processing is complete, valid, accurate, timely and authorised.

This category may be particularly relevant to SaaS products handling financial transactions, automated workflows, data transformations or business-critical calculations.

4. Confidentiality

Confidentiality concerns information designated as confidential and the controls used to protect it.

Examples include access restrictions, encryption, information classification and secure disposal.

5. Privacy

Privacy covers the collection, use, retention, disclosure and disposal of personal information in accordance with applicable commitments and the relevant Privacy criteria.

For European SaaS providers, privacy-related SOC 2 work should be coordinated with GDPR processes rather than treated as a substitute for them.

How should a SaaS company select its Trust Services Criteria?

Start with the service being examined, its contractual commitments, the information it processes and the expectations of customers.

Security is the baseline. The additional categories should be selected when they are relevant to the service and its commitments. Including every category without considering applicability can expand the examination scope unnecessarily.

What Is Changing in the Trust Services Criteria?

The criteria are under review. In October 2026 the AICPA’s SOC 2 Working Group published an exposure draft of proposed 2027 SOC 2 Trust Services Criteria and Description Criteria, with public comment open until January 15, 2027.

The draft restructures the criteria by consolidating duplicated concepts, removing some criteria and adding others where more clarity is needed. It also adds points of focus for emerging technology, including AI governance, model monitoring, prompt manipulation, data poisoning, transparency of AI-generated outputs, training data management and automated decision-making.

If approved in 2027, the updated criteria would apply to engagements beginning on or after December 31, 2027, with early adoption permitted. Until then the current criteria remain in use. Ask your CPA firm which version applies to your engagement, and note that criteria counts and mappings may change.

SOC 2 Type 1 vs Type 2: Which Report Should You Prepare For?

Before beginning SOC 2 audit preparation, management should understand the difference between Type 1 and Type 2 reports.

Both involve an independent CPA examination, but they address different aspects of the organisation’s controls.

	SOC 2 Type 1	SOC 2 Type 2
Evaluates	Design and implementation of controls	Design and operating effectiveness of controls
Time frame	As of a specified date	Over a specified period
Evidence	Control design and implementation records	Records covering the whole period
Typical use	A first independent view of control design	Ongoing assurance for customers that want proof of operation

SOC 2 Type 1

A Type 1 report evaluates the design of controls and whether they are suitably implemented as of a specified date.

It provides a point-in-time view of the organisation’s control environment.

This may be a suitable starting point for companies that need an initial independent assessment of their control design.

SOC 2 Type 2

A Type 2 report evaluates control design and operating effectiveness over a specified period.

It requires evidence demonstrating that relevant controls operated as described throughout the examination period.

For SaaS companies, this means maintaining consistent records of activities such as access reviews, change approvals, security monitoring and vendor assessments.

How Should You Choose?

Consider what your customers request, how mature your existing controls are and whether your organisation can demonstrate consistent operation over the agreed period.

Discuss the expected report type and observation period with the independent CPA firm before planning your readiness timeline. The CPA determines the examination approach and evaluates the evidence.

SOC 2 vs ISO 27001: How Do They Compare?

Both frameworks cover overlapping areas such as access management, risk assessment, supplier oversight and incident management. They are different instruments.

	SOC 2	ISO/IEC 27001:2022
What you receive	Attestation report with a CPA’s opinion	Certificate from a certification body
Who assesses	Licensed, independent CPA firm	Accredited certification body
Basis	AICPA Trust Services Criteria (Security required, four optional categories)	ISO/IEC 27001 requirements plus 93 Annex A controls, selected through risk treatment
Scope	The system or service you describe	The scope of your ISMS
Timing	Type 1 at a date, Type 2 over a period	Initial certification, then surveillance audits and recertification
Typical audience	Customers and prospects, usually under confidentiality terms	Anyone who asks for proof of certification

Existing ISO 27001 evidence can often be reused, but it should be mapped and evaluated against each SOC 2 criterion rather than treated as automatic coverage.

How to Define Your SOC 2 Audit Scope

A clearly defined audit scope helps prevent unnecessary work and makes it easier to determine which systems, teams, vendors and controls belong in the examination.

For a SaaS company, the scope should reflect the service delivered to customers rather than simply covering every business activity without distinction.

1. Identify the Service Being Examined

Start by documenting the SaaS product or service covered by the intended report.

Describe its purpose, principal features, customer-facing functions and the commitments made to customers. This feeds management’s description of the system, which the CPA evaluates against the description criteria and which forms part of the report.

If your company operates multiple products, decide whether they should be included together or whether separate scopes are more appropriate.

2. Map the System Boundaries

Identify the infrastructure, applications, people and processes involved in delivering the service.

This may include:

• Cloud hosting and infrastructure.
• Production databases and application environments.
• Identity and access management systems.
• Development and deployment tools.
• Monitoring and logging services.
• Customer support processes.
• Backup and disaster recovery systems.

3. Identify Third-Party Dependencies

External service providers can influence the security and availability of a SaaS product.

Document cloud providers, payment processors, monitoring services and other suppliers that support the in-scope service.

Review which responsibilities remain with your organisation and which are addressed through the service provider’s controls and assurance reports. Agree with your CPA whether a key supplier is treated as a subservice organisation, and how its controls are presented in the report. Customers will also expect you to state which controls they must operate on their side.

If your suppliers include AI vendors or third-party models, see our guide to AI vendor and third-party risk management and the AI vendor due diligence questionnaire.

4. Document Scope Exclusions

If certain systems, locations, services or business processes are excluded, document the reasoning.

Exclusions should not create a misleading description of the service or omit controls that are necessary to meet customer commitments.

A well-defined scope gives management, control owners and the CPA a common reference point throughout the examination.

How to Assess SOC 2 Controls and Assign Ownership

Once the scope is established, the next step is to evaluate existing controls against the applicable Trust Services Criteria.

A control should have a clear purpose, defined responsibilities and evidence showing how it operates.

Identify Existing Controls

Review current security and operational practices before creating new policies or procedures.

SaaS companies may already operate controls for:

• User access approval and removal.
• Multi-factor authentication.
• Security event monitoring.
• Vulnerability management.
• Software change approvals.
• Backup and recovery.
• Vendor assessments.
• Incident response.
• Employee security awareness.

Existing activities may support relevant SOC 2 criteria, but their applicability and implementation must be assessed individually.

Map Controls to Relevant Criteria

Connect each control to the criteria it supports.

For example, a documented user access review may support relevant logical access criteria under CC6. A formal change approval process may support CC8.1.

A single operational activity can support more than one criterion. However, the mapping should be justified by the control’s actual design and operation.

Assign Control Owners

Every important control should have an accountable owner.

Possible ownership arrangements include:

• Security team: security monitoring, vulnerability management and incident response.
• Engineering team: change management, production access and deployment approvals.
• IT team: identity management and employee access.
• HR team: onboarding, employee departures and security awareness.
• Procurement or compliance team: vendor assessments and supplier documentation.
• Management: policy approval, risk acceptance and oversight.

Control ownership should also define who performs the activity, who reviews it and who retains the evidence.

SOC 2 Evidence Collection and Documentation

Evidence is central to SOC 2 audit preparation. A policy may explain what an organisation intends to do, but the CPA also needs appropriate evidence to evaluate whether controls were implemented and operated.

For a Type 2 examination, evidence must support the relevant operating period.

Common SOC 2 Evidence Examples

Access management evidence

• User access lists.
• Access approval records.
• Periodic access review results.
• Privileged account reviews.
• Employee onboarding and termination records.

Change management evidence

• Change requests and tickets.
• Code review approvals.
• Testing records.
• Deployment logs.
• Emergency change documentation.

Security operations evidence

• Security monitoring records.
• Vulnerability scan results.
• Incident registers.
• Incident investigation records.
• Remediation tracking.

Vendor management evidence

• Third-party inventory.
• Vendor risk assessments.
• Contractual security requirements.
• Relevant supplier assurance reports.
• Periodic vendor review records.

Business continuity evidence

• Backup records.
• Recovery test results.
• Disaster recovery plans.
• Business continuity reviews.

What Makes Evidence Useful?

Good evidence should be relevant to the control, traceable to the activity and appropriate for the period being examined.

Organisations should consider:

• Ownership: Who is responsible for producing and reviewing the evidence?
• Frequency: How often must the control operate?
• Completeness: Does the record demonstrate the full activity?
• Traceability: Can the evidence be linked to a specific control and date?
• Retention: Is it retained according to organisational and contractual requirements?
• Consistency: Does the evidence reflect actual operational practices?

Screenshots alone may not provide sufficient context. Where appropriate, retain supporting records such as approvals, system logs, tickets, and review results.

A structured SOC 2 evidence management approach can help teams connect records with relevant controls and reduce repeated evidence collection.

How to Prepare for a SOC 2 Audit

A readiness assessment helps identify gaps before the independent examination begins.

A practical preparation process can follow these steps.

Step 1: Conduct a Readiness Assessment

Compare existing policies, processes, and technical controls with the applicable Trust Services Criteria.

Record gaps, missing documentation and controls that have not been implemented consistently.

Step 2: Prioritise Control Gaps

Not every gap carries the same level of risk.

Prioritise issues based on their potential impact on the in-scope service, customer commitments and relevant criteria.

Assign owners and target dates for remediation.

Step 3: Implement and Test Controls

Put the required controls into operation.

Check whether procedures are followed consistently and whether the organisation can produce appropriate evidence.

A written policy without supporting operational records may not demonstrate that the control is operating effectively.

Step 4: Organise Audit Documentation

Prepare the system description, policies, control records, risk assessments, vendor documentation and other relevant evidence.

Keep records organised by control, owner and examination period.

Step 5: Conduct an Internal Review

Perform an internal readiness review to identify missing records, inconsistent practices and unresolved exceptions.

This review can help management understand remaining gaps before the CPA begins fieldwork. It does not replace the independent examination.

Step 6: Coordinate With the CPA Firm

Engage the independent CPA early to discuss the scope, selected criteria, report type, observation period and expected evidence.

The CPA evaluates the system description and controls, requests appropriate evidence and issues the report and opinion under the applicable attestation standards.

Common SOC 2 Readiness Mistakes

Even organisations with established security programmes can face delays when their SOC 2 preparation is not properly coordinated.

1. Starting Without a Defined Scope

An unclear scope can result in unnecessary control work or missing system dependencies.

Define the service, infrastructure and supporting processes before beginning detailed control implementation.

2. Treating Policies as Proof of Implementation

A policy describes an expected process. It does not automatically demonstrate that the process operates.

Maintain supporting evidence such as access approvals, review records, tickets and monitoring logs.

3. Assigning Controls Without Clear Ownership

When no individual is accountable, activities can be missed or performed inconsistently.

Assign an owner and define the required review and evidence responsibilities for each control.

4. Collecting Evidence Only Before the Audit

Last-minute evidence collection creates gaps and increases the risk of incomplete records.

Build evidence collection into everyday operations, with a defined cadence and retention approach.

5. Assuming ISO 27001 Automatically Covers SOC 2

Both frameworks address overlapping areas, including access management, risk assessment, supplier oversight, and incident management.

However, their requirements and assessment approaches are not identical. Existing ISO 27001 evidence should be mapped and evaluated against the applicable SOC 2 criteria rather than treated as automatic coverage.

How SOC 2 Compliance Software Supports Readiness

As a SaaS company grows, managing controls, owners, evidence, and audit requests through separate spreadsheets and document repositories can become difficult.

SOC 2 compliance software can help centralise readiness activities and provide a clearer view of control implementation.

A structured solution should support:

• Trust Services Criteria tracking.
• Control mapping and ownership.
• Evidence collection and organisation.
• Access and vendor review records.
• Gap identification and remediation tracking.
• Type 2 observation period management.
• Read-only evidence access for independent auditors.

How AnnexOps Supports SOC 2 Readiness

AnnexOps supports organisations in managing SOC 2 governance activities through connected compliance workflows.

Its SOC 2 capabilities include a Trust Services Criteria hub covering 61 criteria in five categories, a shared control library, evidence management, access and vendor review registers, and Type 2 observation period tracking.

Organisations can also connect relevant controls with existing ISO 27001 records. This can help teams identify where existing evidence may be relevant to SOC 2 without assuming that the frameworks are interchangeable.

The AnnexOps SOC 2 compliance automation solution supports:

• Trust Services Criteria tracking: Organise applicable criteria across the five categories.
• Control mapping: Connect relevant SOC 2 criteria with shared controls and existing framework records.
• Evidence management: Maintain organised supporting records.
• Access and vendor reviews: Track important governance activities.
• Type 2 tracking: Organise evidence against the agreed observation period.
• CPA Audit Room: Provide scoped, read-only access to supporting SOC 2 records.

AnnexOps does not issue SOC 2 reports or replace the independent CPA’s examination. It helps organisations organise their readiness activities and supporting evidence.

Build a Structured SOC 2 Readiness Process With AnnexOps

Preparing for SOC 2 requires clear scope definition, relevant controls, accountable owners and consistent evidence collection. For SaaS companies, these activities should become part of normal security and operational processes rather than a one-time audit exercise.

AnnexOps connects Trust Services Criteria, shared controls, and evidence records through structured workflows. Teams can organise SOC 2 preparation alongside relevant ISO 27001 and other framework activities.

Explore AnnexOps SOC 2 compliance automation to see how your organisation can manage control mapping, evidence, and audit preparation.

Related Reading

• AI Vendor & Third-Party Risk Management Software for EU AI Act Compliance
• AI Vendor Due Diligence Questionnaire: What to Ask
• ISO 42001 Annex A Controls Explained
• GDPR and EU AI Act compliance
• DPO Command Center
• SOC 2 framework page
• ISO 27001 and ISO 42001: How to Integrate Both Standards
• SOC 2 Evidence Collection: What Auditors Expect from SaaS Companies 
• SOC 2 Vendor Risk Management: How to Assess and Monitor Third-Party Providers 
• SOC 2 Access Controls: Managing User Access, Reviews and Audit Evidence 

Author: Nitin Grover

Nitin Grover is an AI compliance strategist and writer focused on EU AI Act compliance, AI governance, Annex IV documentation, AI risk management, and AI compliance operations for AI startups, SaaS companies, and enterprise AI teams across Europe.