Readiness is an operating discipline, not an evidence collection sprint
The audit becomes easier when the SaaS service, its commitments, its risks, its controls and its evidence already operate as one connected management system.
SaaS companies often begin by collecting policies and screenshots. That may create a document library, but it does not establish that controls are suitably designed or operating consistently. Readiness starts by defining the service customers rely on, the commitments made to them and the system that delivers those commitments.
The control environment should then respond to real risks in product development, identity, cloud infrastructure, data handling, operations, suppliers and incident response. Each control needs an accountable owner, a practical operating frequency, a clear exception path and evidence that can be reproduced without emergency effort.
Leadership test
Can management explain which controls protect each important customer commitment and provide evidence that those controls operated during the intended period?
Common failure
Policies describe an ideal process while engineering and operations follow a different process in practice.
Exhibit 1: Readiness operating model
- Customer commitments — contracts, service promises and requirements.
- System boundary — people, processes, technology, data and dependencies.
- Risk assessment — threats, vulnerabilities, changes and service impact.
- Control operation — owners, frequency, exceptions and management review.
- Evidence and assertion — proof of operation and management sign-off.
- Continuous management review, exception handling and improvement connects every stage.
Choose the report type and criteria before building the evidence plan
SOC 2 reports address controls relevant to security, availability, processing integrity, confidentiality or privacy. The selected scope should reflect the service commitments and system requirements that matter to intended users.
SOC 2 Type 1
Evaluates whether the controls are suitably designed at a specified date. It can establish a baseline when the control environment is new or materially changed.
SOC 2 Type 2
Evaluates control design and operating effectiveness over a defined period. It requires consistent evidence throughout the review period.
Trust Services Categories
- Security — protection against unauthorized access, use or disclosure and damage to systems.
- Availability — systems are available for operation and use as committed or agreed.
- Processing integrity — processing is complete, valid, accurate, timely and authorized.
- Confidentiality — information designated as confidential is protected as committed or agreed.
- Privacy — personal information is collected, used, retained, disclosed and disposed of according to commitments and criteria.
- Define intended report users.
- Confirm service commitments.
- Select relevant categories.
- Choose Type 1 or Type 2.
- Agree the review date or period.
Practical advice
Do not add categories simply to make the report look broader. Each selected category creates additional description, control and evidence expectations.
Timing
A Type 2 report needs enough operating history to support meaningful testing across the review period.
Scoping principle
Security is included in every SOC 2 engagement. Additional categories should be selected when customer commitments or system requirements make them relevant.
Define the service system before deciding which controls are in scope
The system description should explain how the SaaS service is designed and operated, not merely list technologies. It should be consistent with contracts, architecture, customer documentation and actual operating practice.
Elements of the system description
- Services provided — products, features, customer use cases, service levels and delivery channels included in the report.
- Infrastructure and software — cloud services, applications, data stores, networks, code, tools and supporting platforms.
- People and procedures — engineering, security, operations, support, finance, legal, human resources and control activities.
- Data and information — customer data, operational records, logs, configuration, source code and evidence repositories.
- System boundaries — included environments, excluded services, locations, legal entities and report period.
- Subservice organizations — cloud, payment, identity, support and other providers whose services contribute to the SaaS system.
| Scope question | Evidence to resolve it |
|---|---|
| What exactly do customers buy? | Contracts, product descriptions, data flow, architecture and service commitments. |
| Which systems deliver the service? | Asset inventory, cloud accounts, repositories, production services and support tools. |
| Which teams operate the controls? | Organization chart, role descriptions, control ownership and escalation paths. |
| Which providers are relied upon? | Supplier register, contracts, assurance reports, responsibilities and incident obligations. |
Boundary test
If a process, technology, person or provider can materially affect the service commitments, it should be explicitly considered in scope.
Avoid this trap
Do not scope only the production cloud account while ignoring source code, support, identity, monitoring, change approval and supplier dependencies.
Description quality
The system description should be complete enough for intended users to understand how the service operates and where responsibilities sit.
Connect controls and evidence to the actual service delivery architecture
A credible readiness model shows how identity, development, cloud operations, customer commitments and external providers combine to deliver the SaaS service.
Exhibit 2: Vendor neutral SaaS service system
- Users and support functions — employees, customers, partners, engineering, security and operations.
- Identity and access — authentication, authorization, privilege and lifecycle.
- SaaS application platform — web and API services, business logic, tenant controls and administrative functions.
- Secure delivery — source control, review and testing, release approval and change evidence.
- Cloud and data platform — production accounts, data stores and backups, networks and secrets, monitoring and resilience.
- Customer commitments — security requirements, availability targets, data protection promises and incident obligations.
- Subservice organizations — cloud hosting, identity services, support and communications, payment and monitoring.
- Evidence, monitoring, incident records, approvals, reviews and management oversight run across the whole system.
- Control placement — place controls where the risk is created, changed or observed rather than only in a central compliance function.
- Evidence source — prefer authoritative system records from identity, cloud, source control, ticketing and monitoring platforms.
- Boundary discipline — document excluded services and explain why they cannot materially affect the scoped commitments.
Design controls from risks and commitments, not from a generic checklist
The control set should explain how the organization addresses the risks that could prevent the SaaS service from meeting its commitments and system requirements.
- Commitment — what has been promised to customers or required by the business?
- Risk — what event or condition could prevent the commitment from being met?
- Control — what activity prevents, detects or corrects the risk?
- Evidence — what proves the activity occurred and exceptions were resolved?
Control owner test
Can the owner explain the risk, demonstrate the control, identify the population and show how exceptions are handled?
| Design element | Readiness expectation | Example evidence |
|---|---|---|
| Control objective | States the outcome the control is intended to achieve. | Control matrix linked to risks and Trust Services Criteria. |
| Control activity | Describes who acts, what they do, when and using which system. | Procedure, workflow, approval logic and owner record. |
| Frequency and population | Defines when the control runs and the complete set of items it applies to. | Scheduled reports, system queries and population reconciliations. |
| Exception handling | Defines how failures are recorded, assessed, corrected and approved. | Issue tickets, risk acceptance and closure evidence. |
| Evidence quality | Shows the activity, date, actor, result and relevant context. | System generated logs, approvals and immutable records. |
Weak design
"Management reviews security regularly" is too vague. The review scope, frequency, participants, evidence and decision rights are not defined.
Automation
Automation improves consistency only when configuration, ownership, monitoring and exceptions are also controlled.
Design principle
A control should be specific enough that another qualified person can understand how it operates and distinguish normal performance from an exception.
Prioritize the control domains that most directly affect SaaS trust
The exact control set depends on scope and risk. The domains below are common foundations for a SaaS service preparing for SOC 2.
01 Governance and oversight
Roles, policies, risk appetite, management review, ethics, accountability and exception approval.
02 Identity and access
Joiner, mover and leaver events, strong authentication, privilege, service identities and access reviews.
03 Asset and configuration
Inventories, ownership, secure baselines, cloud configuration, secrets and unauthorized change detection.
04 Secure development
Source control, peer review, testing, dependency risk, release approval and separation of duties.
05 Security operations
Logging, alerting, vulnerability management, incident response, evidence preservation and lessons learned.
06 Data protection
Classification, encryption, access, retention, deletion, export, backup and customer data handling.
07 Availability and resilience
Capacity, redundancy, backup, restoration, recovery objectives, testing and service continuity.
08 Third party assurance
Due diligence, contracts, responsibilities, monitoring, assurance reports and exit planning.
| Domain | Minimum readiness evidence | Common exception |
|---|---|---|
| Access | Approved roles, current user population, privilege records and timely removal. | Inactive or former users remain enabled. |
| Change | Complete deployment population, review, testing, approval and traceability. | Emergency or direct production changes bypass the normal path. |
| Operations | Monitoring coverage, incidents, vulnerability actions and review records. | Alerts exist but ownership and closure evidence are inconsistent. |
| Resilience | Backup coverage, restore tests, recovery targets and management review. | Backups are configured but restoration has not been demonstrated. |
Control balance
Policies establish direction. Technical controls enforce and record. Management controls review performance and decide how exceptions are treated.
Build evidence as part of control operation, not after the period closes
Type 2 readiness depends on evidence that is complete, attributable, timely and consistent across the review period.
Exhibit 3: Evidence lifecycle
- Control event — a user review, release, alert, backup, approval or other control activity occurs.
- Authoritative record — the system captures date, actor, population and result.
- Owner review — the owner confirms completeness, investigates exceptions and records decisions.
- Evidence package — the retained record links the control, population, exception, remediation, approval and management reporting.
- Shows date and period.
- Identifies actor and approver.
- Supports the complete population.
- Shows result and exception.
- Links remediation and closure.
Preferred sources
- Identity logs, cloud records, source control, deployment systems, ticketing, vulnerability tools and monitoring platforms.
Weak evidence
Undated screenshots, manually edited spreadsheets, incomplete samples and records created only after the auditor asks.
Operating effectiveness
Evidence should show that the control operated as designed for the relevant population and period, including how exceptions were identified and resolved.
Control the product change path and the providers that support it
For SaaS companies, control failures often arise in software delivery, cloud configuration and outsourced services. Readiness should make those dependencies visible and accountable.
Secure delivery chain
- Code and configuration — authorized repositories, protected branches, traceable authorship and secret control.
- Review and testing — peer review, automated testing, dependency scanning and security validation.
- Approval and release — approved deployment path, environment separation and production authorization.
- Monitoring and rollback — release evidence, health checks, incident linkage and tested rollback capability.
| Responsibility area | SaaS company evidence | Provider evidence |
|---|---|---|
| Cloud security | Account structure, identity, network, configuration, logging and workload controls. | Provider assurance report, service commitments and incident obligations. |
| Identity service | Tenant configuration, administration, lifecycle, conditional access and monitoring. | Service availability, security controls and relevant assurance report. |
| Support tools | Data minimization, access approval, retention, integration and offboarding. | Contract, security terms, privacy terms and incident support. |
| Payment or communications | Scoped data flows, customer disclosure, access and exception monitoring. | Applicable compliance evidence and service commitments. |
Release population
Maintain a complete list of production changes so the organization can demonstrate that every change followed the approved path.
Provider risk
Track services that store customer data, can change production, authenticate users or affect availability.
Assurance review
Review provider reports, exceptions and complementary controls rather than filing the reports without analysis.
Move through scope, design, operation and examination preparation
A readiness roadmap sequences the work so material controls are stable before the review period begins.
- Choose Type 1 or Type 2; define service and system boundary; map commitments and dependencies; complete readiness risk assessment. Exit gate: scope and system boundary approved by management.
- Update policies and procedures; correct access and change gaps; define evidence sources; resolve high risk exceptions. Exit gate: controls are designed and ready to operate.
- Reconcile populations; capture authoritative evidence; review exceptions and remediation; test backup and incident processes; perform internal readiness testing. Exit gate: evidence demonstrates stable control operation.
- Confirm review date or period; prepare management assertion; organize auditor evidence access; track requests and findings; maintain controls during fieldwork. Exit gate: management accepts the scope, assertion and residual readiness risk.
| Stage benchmark | Target |
|---|---|
| Critical controls have named owners | 100% |
| In scope systems map to the system description | 100% |
| Unresolved high risk readiness exceptions | 0 |
| Controlled evidence repository and request process | 1 |
Timing principle
Do not begin a Type 2 period while material controls are still being redesigned. Evidence of unstable operation can create avoidable exceptions.
SOC 2 readiness checklist for SaaS companies
Use this checklist to confirm the minimum operating evidence before asking the auditor to begin the examination.
| Readiness area | Minimum evidence |
|---|---|
| Report objective | Intended users, report type, selected categories, review date or period and auditor engagement objective are approved. |
| System scope | Services, legal entities, environments, people, processes, technologies, data and exclusions are documented. |
| System description | The description matches contracts, architecture, operating practice and subservice relationships. |
| Risk assessment | Risks reflect customer commitments, service changes, threats, dependencies and business impact. |
| Control matrix | Each control has an owner, objective, activity, frequency, population, evidence source and exception path. |
| Identity and access | User lifecycle, privilege, authentication, service identities and access reviews operate consistently. |
| Secure delivery | Production changes are traceable through review, testing, approval, deployment and monitoring. |
| Security operations | Logging, vulnerability management, incidents, alert response and corrective actions are evidenced. |
| Resilience | Backup coverage, restoration tests, recovery targets, availability monitoring and continuity responsibilities are current. |
| Subservice organizations | Providers, responsibilities, assurance reports, exceptions and complementary controls are reviewed. |
| Evidence readiness | Complete populations, authoritative records, retention, access and request tracking are established. |
| Management responsibility | Management has reviewed scope, residual gaps, the system description and the intended assertion. |
Ready to begin
Scope is stable, controls operate, evidence is reproducible and material exceptions have accountable remediation.
Delay the examination
Core controls are still being redesigned or the evidence period does not reflect normal operation.
Management decision
Accept the review date or period only after confirming residual readiness risk.
Reference sources and publication scope
The sources below provide the authoritative basis for the SOC 2 report model, Trust Services Criteria and system description concepts used in this advisory.
- AICPA 2017 Trust Services Criteria with revised points of focus 2022 — criteria for evaluating controls relevant to security, availability, processing integrity, confidentiality and privacy.
About this advisory
This publication provides general, vendor neutral readiness guidance. It does not constitute an audit opinion, legal advice or CPA attestation.