A SOC 2 audit is an independent examination of whether a SaaS company’s controls match the system it describes and the Trust Services Criteria in scope. In practice, the work moves from scoping and readiness, through evidence collection and auditor testing, to follow-up, draft review, and final report issuance.
For SaaS teams, not just a document upload exercise. The auditor is trying to verify that the controls management says exist are suitably designed—and, for Type II, operated effectively over the review period.
What a SOC 2 audit is — and what it is not
A SOC 2 examination evaluates controls relevant to selected Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. The scope should identify the system being examined and the criteria addressed; not every SOC 2 report covers all five categories or the same controls. The AICPA’s Trust Services Criteria define the criteria used for these examinations.
SOC 2 is an attestation report, not a self-issued badge. Management prepares a description of the system and makes an assertion against the applicable description criteria and Trust Services Criteria; the service auditor issues a report expressing an opinion on the matters examined, as described in AICPA guidance on SOC 2 reporting.
The report is signed by a licensed CPA firm. Audit teams may include specialists, but the SOC examination is performed under AICPA attestation standards, and the engagement must preserve the practitioner’s independence, objectivity, and competence. The Cloud Security Alliance’s explanation of why SOC reports are issued by CPA firms is a useful plain-language summary of that requirement.
For a SaaS team, that means the auditor is not there to run your controls, approve your tooling, or write your policies. Management owns the system, controls, and assertion, the auditor evaluates them independently.
Type I vs Type II: why the audit period changes the work
A Type I SOC 2 report addresses the description and design of controls as of a specified date. A Type II report also addresses whether controls operated effectively throughout a specified period, so it requires evidence of operation during that period, according to AICPA SOC 2 examination guidance.
The practical difference is basically evidence depth.
If the control says production access is reviewed quarterly:
- In a Type I examination, the auditor may focus on whether the control is designed appropriately at the point in time examined.
- In a Type II examination, the auditor needs support that the review operated during the period being examined.
That can mean showing records for multiple review cycles, who performed the reviews, what access was reviewed, whether changes were identified, and whether those changes were resolved. The exact request depends on the control wording, scope, period, and auditor procedures.
The SOC 2 audit process, step by step
SOC 2 engagements vary, but SaaS teams can usually understand the work in this operating sequence.
1. Initial planning and auditor engagement
The company selects and engages an independent CPA firm to perform the examination. Early conversations usually clarify the service being examined, the expected report type, timing, major systems, and internal stakeholders.
For SaaS companies, this often means identifying the product or platform in scope, the cloud environment, identity provider, ticketing system, HR system, endpoint management system, and key vendors that support the service.
2. Scope definition
Scope determines what the auditor will examine. It should identify:
- the system or service covered by the report
- the Trust Services Criteria included
- relevant infrastructure, applications, data, people, processes, and vendors
- the boundaries of the control environment
This matters because evidence only makes sense against scope. A change-management ticket for an internal tool may not be relevant if the audited system is the production SaaS platform. A vendor review may matter if that vendor supports a critical part of the service.
3. Readiness or gap review
Many teams choose to perform a readiness review before the formal examination. This is not the SOC 2 report itself. It is a preparation step used to compare current controls and evidence against the expected scope.
A readiness review may reveal that a policy exists but has not been approved, access reviews are happening but not retained, or vendor reviews are informal and not tied to a defined process.
4. Remediation before formal audit work
If gaps are found early, the team can decide what to fix before the audit period or examination date. Examples include clarifying control language, assigning owners, retaining evidence, tightening access procedures, or documenting risk decisions.
For Type II, timing matters because the auditor evaluates operation during the defined period. A control that starts operating after the period ends cannot prove it operated throughout that period.
5. Evidence request list and collection
The auditor provides requests based on the scoped controls and criteria. Evidence may include policies, system configurations, screenshots, exports, tickets, access review records, change records, training records, incident records, vendor reviews, and HR records.
The security or GRC owner often coordinates the request list, but the evidence usually lives across engineering, IT, HR, finance, procurement, and leadership.
6. Auditor fieldwork
During fieldwork, the auditor tests whether the evidence supports the control description and audit objective. In a Type II examination, the report includes details of tests of controls and their results; the auditor evaluates whether controls were suitably designed and operated effectively to provide reasonable assurance against the applicable criteria, as explained in the AICPA’s overview of SOC 2 and SOC for Cybersecurity distinctions.
Fieldwork may involve reviewing submitted records, asking questions, selecting samples, requesting walkthroughs, or asking for additional support where the original evidence does not resolve the test objective. If work is conducted remotely, this may happen through secure evidence exchange, screen sharing, system exports, and ticketing-system records, depending on the engagement and auditor.
7. Follow-up requests and clarifications
Follow-up is normal. It does not automatically mean something failed.
The auditor may ask for clarification because a screenshot lacks a date, a ticket does not show approval, an access review export does not identify the reviewer, or a policy does not match the control wording. The team’s job is to respond with evidence that directly answers the request, not to flood the auditor with unrelated documents.
8. Exception review
If the evidence does not support the control, or if the control did not operate as described, the auditor evaluates the deviation in the context of the engagement, criteria, scope, and report.
Outcomes depend on the facts. The auditor may request more support, document a testing result, evaluate whether the matter affects the opinion, or discuss the issue with management. Management can explain context, but the auditor’s conclusion remains independent.
9. Draft report
After testing and internal audit review, the auditor provides draft report materials. Management reviews its system description and assertion for accuracy. The auditor remains responsible for the opinion.
For Type II reports, testing and results may be included in the report, so unresolved deviations can appear in the audit record and report treatment depending on auditor judgment and the engagement facts.
10. Final report issuance
Once open items are resolved and the report is finalized, the licensed CPA firm issues the SOC 2 report. The final report reflects the scoped system, applicable criteria, management assertion, auditor opinion, and, for Type II, tests of controls and results.
11. Ongoing monitoring
If the company intends to maintain SOC 2 reporting over time, the work should not stop when the report is issued. Or more accurately, it should not disappear until the next audit window. Controls need owners, evidence needs to be retained, and changes to systems, vendors, people, and processes should be reflected in the control environment before the next examination cycle.
What evidence auditors request and how they test it
Auditors do not collect evidence merely to populate a folder. They test whether the evidence supports the control as written.
If the control says, “Management reviews production access on a quarterly basis,” the auditor needs support for the important parts of that sentence:
- Was production access actually reviewed?
- Was the review performed by the appropriate owner?
- Did the review happen during the relevant period?
- What users, roles, or systems were included?
- Were inappropriate access rights identified?
- If changes were needed, were they tracked to completion?
A clear internal check is whether each record is clear about what happened, who performed or approved it, when it happened, and which system, population, or period it covers. This is not a universal AICPA checklist; it is a practical way to avoid evidence that looks helpful but does not answer the audit question.
Common evidence problems include:
- screenshots without dates or system context
- exports that do not show the complete population
- tickets that show work was done but not approved
- policies that describe a process the team does not actually follow
- access reviews that identify issues but do not show resolution
- vendor reviews stored in email without a clear owner or date
- HR records that do not tie cleanly to onboarding or offboarding controls
The best evidence is specific to the control. A broad policy may support design, but it usually does not prove a recurring control operated during a Type II period.
Example: following one SaaS control from request to report
The following example is illustrative. Actual control wording, evidence requests, testing, follow-up, and report treatment vary by scope, auditor, and engagement facts.
| Audit step | Example: quarterly production access review |
|---|---|
| Control statement | “Production access is reviewed quarterly by an authorized owner, and inappropriate access is removed.” |
| Typical internal owner | Security or IT may coordinate; engineering or infrastructure leadership may validate production roles and privileged access. |
| Illustrative evidence request | “Provide evidence of production access reviews performed during the period, including the user population reviewed, reviewer, review date, identified changes, and evidence of completion.” |
| What the SaaS team submits | Access review exports from the identity provider or cloud platform, reviewer sign-off, tickets for removals or role changes, and a list of users or roles included in the review. |
| What the auditor checks | Whether the evidence matches the control: the review occurred, covered the relevant production access population, was performed by the appropriate person, occurred in the relevant period, and tracked required changes. |
| Possible follow-up | “How do we know this export is the full production access population?” “Who approved this review?” “Where is the ticket showing this user’s access was removed?” “Why is one quarter missing?” |
| Incomplete evidence | A screenshot of an access list with no review date, no reviewer, no indication of approval, or no evidence that identified changes were completed. |
| Possible audit outcome | If evidence supports the control, the auditor can document the test and result. If evidence is missing or inconsistent, the auditor evaluates the deviation in context and determines report treatment based on the engagement facts. |
This is the audit-room pattern SaaS teams should internalize: the auditor starts with the control, requests evidence, tests whether the evidence proves the control operated as described, asks follow-up where the record is unclear, and documents the result.
What happens if evidence is missing or a control has an exception
Missing evidence does not automatically mean the whole audit fails. It does mean the auditor cannot rely on unsupported assertions.
If a record is incomplete, the auditor may ask for additional support. For example, if an access review export shows users but not reviewer approval, the team may be asked for the approval record. If a change ticket shows deployment but not code review, the team may be asked for the pull request or approval trail.
If the team cannot provide support, or if the control did not operate as described, the auditor evaluates the issue in context. Factors may include the control, the period, the population affected, whether the issue is isolated or recurring, and how it relates to the applicable criteria.
Remediation timing matters. Fixing the process after an issue is found may improve future operations, but it does not necessarily prove the control operated during the period already under examination. For Type II, the auditor is concerned with operation throughout the specified period, which is the part that can get missed.
Management can provide explanations and context, especially where facts need clarification. But management does not decide the audit conclusion. The auditor’s role is to independently evaluate the evidence and issue the report.
Who owns the audit work on a SaaS team
A security or GRC lead can coordinate the audit, but they usually cannot produce every piece of evidence alone. SOC 2 work cuts across the systems and teams that operate the SaaS business.
The table below is an ownership pattern, not a universal RACI or AICPA requirement.
| Team or role | Typical contribution during a SOC 2 audit |
|---|---|
| Security / GRC | Coordinates scope, maps controls, manages evidence requests, tracks open items, communicates with the auditor, and helps align evidence to control language. |
| Engineering | Provides change-management evidence, production deployment records, secure development evidence, infrastructure configuration support, and production-access context. |
| IT | Supports identity and access management, device management, endpoint controls, access provisioning and deprovisioning records, and system configuration evidence. |
| HR / People | Provides onboarding and offboarding records, training completion records, policy acknowledgement evidence, and background-check evidence where applicable to scope. |
| Finance / procurement / vendor owner | Provides vendor inventory, vendor review records, contract or due diligence evidence, and ownership details for critical service providers. |
| Leadership | Approves policies, supports risk decisions, owns management assertion, sponsors remediation, and resolves cross-functional priority conflicts. |
| External auditor | Performs independent testing, requests follow-up, evaluates deviations, forms conclusions, and issues the SOC 2 report through the licensed CPA firm. |
In practice, the lesson is plain: assign control owners before fieldwork starts. If ownership is unclear, evidence requests stall, and the audit turns into a search exercise instead of a verification exercise.
Timeline, renewal, and how to avoid the evidence scramble
A SOC 2 audit has planning, scoping, evidence collection, fieldwork, follow-up, draft review, and final issuance phases. The duration depends on scope, report type, readiness, auditor procedures, and how quickly the team can provide usable evidence.
Type II requires earlier planning because the auditor needs evidence from the defined review period. Waiting until fieldwork to discover that access reviews were not retained or change approvals were not captured creates avoidable friction.
The better operating model is to keep controls and evidence current as the business runs:
- define control owners
- store evidence where it can be retrieved
- keep policies aligned with actual workflows
- review access, vendors, incidents, and changes on the cadence your controls describe
- update control language when systems or processes change
- resolve evidence gaps before the auditor asks for them
This is where Ciphrix’s approach fits: compliance should run as an operating system, not a periodic document chase. For SaaS teams preparing for SOC 2, that means aligning policies, systems, risks, owners, and evidence throughout the year so the audit can focus on verification rather than reconstruction.
If you are preparing for your first SOC 2 audit, start by asking whether each scoped control has a clear owner and evidence that shows what happened, who did it, and when. That is the simplest way to make the audit process more predictable without confusing preparation with the auditor’s independent work.