SOC 2 is a voluntary attestation, but most enterprise buyers now ask for it contractually, and once you commit to it, user acceptance testing is in scope whenever it touches security, processing integrity, confidentiality, or availability. Passing the audit means your UAT process produces consistent, time-stamped artifacts, stores them securely, and ties every test back to a documented procedure and a named control owner.

TL;DR:

Effective SOC 2 compliance requires maintaining detailed, time-stamped UAT artifacts linked to specific builds, environments, and verified control owners.

Controls around security, processing integrity, confidentiality, and availability must be both designed and operated consistently during the audit period.

Automating evidence collection with session replays, real-time transcription, and structured issue reports reduces audit delays and improves artifact reliability.

A SOC 2 report from your cloud provider covers infrastructure but does not validate your application or testing controls, which remain your responsibility.

Preparing for audit involves standardizing session identifiers, enforcing SSO, defining retention rules, and ensuring traceable, complete evidence over the entire audit window.

Wezardapp

wezardapp.com

Make UAT Evidence Easier to Trace

Wezard records screens, transcribes issues in real time, and detects duplicate tickets before they reach your Jira or Azure DevOps backlog.

Visit Wezard

Which Trust Services Criteria apply to your UAT process
UAT artifacts auditors want: a practical checklist
How to run audit-ready UAT: process and configuration
Cloud provider SOC 2 reports versus your own UAT controls
Timeline, effort, and common pitfalls
Why integrated UAT tooling reduces audit friction
Making your UAT evidence SOC 2 ready with Wezard
FAQ
Sources

Which Trust Services Criteria apply to your UAT process

SOC 2 reports are built around the AICPA’s Trust Services Criteria, and auditors expect to see most of them reflected somewhere in your testing activities. You don’t need every criterion to apply to every test cycle, but you do need to know which ones your UAT work touches and be able to show it.

Security: access controls on test environments, including who can view, run, or approve tests.
Processing integrity: accurate test execution, correct defect routing, and traceable handling of failed test cases.
Confidentiality: how test data, especially anything resembling production data, is masked, stored, and shared.
Availability: whether test environments stay stable enough to support repeatable, documented test runs.

For each criterion in scope, auditors look for two things: that a control exists on paper (design effectiveness) and that it was actually followed during the audit period (operating effectiveness). A written UAT policy that nobody follows fails the second test just as hard as having no policy at all. That’s why control ownership matters: someone specific, usually a QA lead or compliance owner, needs to be accountable for each control, not a team in the abstract.

UAT artifacts auditors want: a practical checklist

Auditors don’t ask for proof that your software works. They ask for proof that your process worked, consistently, across the audit window. According to A-LIGN’s guide to SOC 2, evidence quality determines audit velocity, and an undocumented control activity is treated the same as a control that never happened.

Prioritize these five artifact types:

Time-stamped test logs and results tied to a specific build number or environment, not a vague “latest version.”
Issue reports with reproduction steps, attachments, and timestamps, including the full workflow history from open to close.
Session recordings or replays with transcripts that show exactly what the tester did and what the system showed at that moment.
Deployment and change records that link the tested code to the version that actually shipped to production.
Access logs and approvals tied to named control owners, not shared logins or generic service accounts.

Audit-ready evidence doesn’t require perfect tests, it requires traceable ones. Organizations commonly fail audits because of gaps in the paper trail rather than gaps in quality, a pattern A-LIGN and other auditors flag repeatedly: inconsistent naming, missing timestamps, and orphaned tickets with no link back to a test session. Our notes on what auditors sample in bug reporting go deeper on the specific metadata fields that come up most in sample requests.

How to run audit-ready UAT: process and configuration

Most of the audit-readiness problem is solved before the audit starts, with a handful of configuration decisions your QA and security teams can make together.

Standardize session identifiers: every test session needs a start timestamp, end timestamp, build ID, and environment name, applied consistently across every tester.
Enforce SSO for test accounts: use SAML or OIDC with SCIM provisioning so access is tied to a real identity, not a shared credential, and document role separation in an access control matrix. Our SSO configuration runbook walks through SAML/OIDC and SCIM setup for testing tools specifically.
Require structured issue reports: attach session replay clips and logs automatically rather than relying on testers to remember to paste screenshots.
Set retention and redaction rules: define how long recordings are kept, who can access them, and how personal data gets masked before storage.
Align evidence retention with your audit window: a Type II audit samples activity across months, so evidence that disappears after 30 days is effectively evidence you never had.

Pro Tip: Name test sessions with a fixed pattern like BUILD-ENV-DATE-TESTER from day one; retrofitting naming conventions after an audit request arrives is far more painful than enforcing them up front.

Cloud provider SOC 2 reports versus your own UAT controls

A SOC 2 report from your cloud provider covers their infrastructure, not your application or your testing process. Google Cloud publishes third-party SOC 2 Type II reports through its compliance portal, and similar reports exist for other major providers, but those reports stop at the infrastructure layer.

What the provider’s report covers: physical security, network controls, and platform-level availability for the infrastructure you rent.
What you still own: test data handling, application-level access controls, UAT session logs, and anything your own team configures on top of the platform.
What to include in your evidence package: the provider’s SOC 2 report itself, plus a bridge letter if there’s a gap between report periods and your audit window.
What auditors will ask regardless: who approved test access, how test data was masked, and whether your application controls matched your documented policy.

Timeline, effort, and common pitfalls

Quick wins, like standardizing timestamps and enforcing SSO on test accounts, can happen in a matter of weeks. Building a full evidence program that survives a Type II sample request typically takes two to six months, depending on how mature your documentation already is.

QA leads own test execution, naming conventions, and issue report completeness.
Security or compliance teams own the access control matrix, retention policy, and evidence mapping to criteria.
DevOps owns the link between deployment records and the builds that were actually tested.
The most common failure points: missing timestamps, inconsistent session naming, issue tickets without reproduction steps, and recordings kept too briefly to cover the audit window.

Why integrated UAT tooling reduces audit friction

Manual evidence collection is where most audit timelines break down. Every screenshot someone forgets to attach, every ticket missing a timestamp, becomes a follow-up question from the auditor and a delay on your side.

Tooling that automatically generates session replay, transcribes tester narration in real time, and flags duplicate tickets before they reach your backlog produces evidence that’s consistent by default rather than by discipline. That consistency is exactly what turns a scattered UAT process into one an auditor can sample quickly. A practical next step is to pilot this approach across a few UAT cycles, review your access runbooks, and pull together a sample evidence packet before your auditor asks for one, a workflow we cover in our UAT and bug reporting use cases.

— Marketing

Making your UAT evidence SOC 2 ready with Wezard

We built Wezard around the idea that UAT evidence should be a byproduct of testing, not a separate project you scramble through before an audit. Every session gets recorded, every issue gets a real-time transcript attached, and duplicate tickets get caught before they ever reach Jira, Azure DevOps, or ServiceNow.

Session replay captures exactly what a tester saw and did, with timestamps built in.
Real-time transcription turns spoken issue reports into structured text automatically.
AI duplicate detection keeps your backlog, and your evidence trail, free of redundant tickets.
SSO integration ties every test session to a verified identity instead of a shared login.
Secure retention keeps recordings available for the length of your audit window without manual archiving.

If you’re preparing for a SOC 2 cycle, a good starting point is a short pilot: run a few UAT cycles through the tool, pull a sample evidence packet, and compare it against what your auditor typically asks for. For teams earlier in the process, our guide to SOC 2 for startups lays out a practical first-audit path that pairs well with this approach. For current pricing details, see our pricing page.

FAQ

Is SOC 2 legally required?

No, SOC 2 is a voluntary AICPA attestation rather than a law, but many enterprise customers require it contractually before they’ll sign a vendor agreement. The FTC’s guidance on vetting service providers encourages buyers to verify vendor security practices, which is a major reason SOC 2 reports get requested in the first place.

Is Google Cloud SOC 2 compliant?

Yes, Google Cloud publishes third-party SOC 2 Type II reports covering its infrastructure. That report doesn’t extend to the applications or UAT processes customers build on top of the platform, so those remain the customer’s own responsibility to document.

Who needs SOC 2 Type II compliance?

Any organization that handles customer data and wants to sell into enterprise or regulated markets typically needs it, since many buyers now require a current report before signing. Service providers subject to obligations like the FTC Safeguards Rule often push this requirement down to their own vendors as well.

How hard is it to get SOC 2 compliant?

Difficulty depends heavily on how mature your documentation already is: teams with consistent logging and access controls can prepare in weeks, while those starting from scratch often need two to six months. The hardest part is rarely the technical controls themselves, it’s producing consistent, traceable evidence across the whole audit window.

What UAT evidence matters most for a SOC 2 audit?

Auditors weigh consistency over perfection, so time-stamped test logs, issue reports with reproduction steps, and session recordings tied to specific builds matter most. A single well-documented test session with clear metadata holds more audit value than ten sessions with no timestamps or ownership attached.