How to Prepare Defensible SaaS Compliance Evidence for Your Next SOC 2 Audit

The SOC 2 examination has matured considerably over the past several reporting cycles. Auditors who previously accepted point-in-time screenshots and a representative sample now routinely ask for continuous evidence, complete inventories, and explicit treatment of third-party data flows. The result is an examination experience that punishes organizations whose evidence is well-curated but incomplete.

This article describes a six-section evidence package designed to survive contemporary auditor expectations for SaaS-related controls in particular. It assumes familiarity with the AICPA SOC 2 Trust Services Criteria and is structured around the common-criteria items most directly affected by modern SaaS adoption.

Section one: complete inventory of SaaS systems in scope

The threshold question every auditor will ask is whether the inventory of in-scope systems is genuinely complete. A list assembled from procurement records, the identity provider, and the SSO catalog will not be complete. Modern auditors are increasingly familiar with this gap and will probe it directly. Produce a reconciled inventory drawing from at least four sources: identity provider applications, expense and procurement records, OAuth grant tables, and an independent discovery scan. Document the reconciliation methodology so the auditor can evaluate the work.

Section two: access provisioning and deprovisioning evidence

For each in-scope system, demonstrate that user access is granted only through approved request workflows and revoked promptly on role change or departure. The evidence should include the request ticket, approver identity, provisioning timestamp, and corresponding deprovisioning event. Auditors increasingly request median and 95th-percentile deprovisioning times across the population. Spreadsheet exports without source-system identifiers are no longer sufficient.

Section three: authentication and access controls

Document the authentication posture of every in-scope system. This includes single sign-on enrollment, multi-factor authentication enforcement, session timeout configuration, and exceptions. Where an application supports SSO but is not federated, the exception should be tracked as a finding rather than omitted. Reference frameworks such as NIST CSF 2.0 and the CISA Zero Trust Maturity Model directly when motivating the controls, since auditors often cite them in observations.

Section four: third-party access via OAuth

OAuth grants are now a recurring auditor question and represent third-party data access that historically went unexamined. Produce an inventory of OAuth grants in workspace tenants in scope, the scopes they request, the date of consent, and the review status. Document the consent control — whether grants require admin approval and what scopes are restricted — and provide the corresponding policy. The case study on a financial-services compliance failure illustrates why this evidence matters in practice.

Section five: change and configuration management for SaaS-side AI

An emerging line of inquiry concerns AI features inside SaaS applications. When a vendor enables a new AI capability that processes customer data, this represents a material configuration change that may not surface through the customer's standard change management process. Document the review process for vendor-side feature changes, including how the security team monitors vendor product changelogs and how the data processing addenda are updated. A companion guide on identifying vendors training AI models on your data describes the relevant signals.

Section six: continuous evidence and exception handling

Where controls operate continuously, evidence should be continuous as well. Configure exports from the source systems that produce time-series evidence of the control's operation — for example, the daily deprovisioning report rather than a single screenshot. Document each exception, the compensating control, and the remediation timeline. Auditor responses to exceptions are now driven more by the quality of the management discussion than by the existence of the exception itself.

Reducing the preparation burden

The work above is significant. Performed manually it consumes weeks of senior security and GRC time, and produces evidence that begins to age the moment it is collected. A continuous discovery layer that supplies the inventory, OAuth, and identity data underneath the evidence package reduces this burden considerably. Waldo Security's SaaS Governance and Compliance overview maps directly to the SOC 2 Common Criteria most affected by SaaS adoption, with evidence exports designed for auditor consumption.

If you would like a walkthrough of how the evidence package looks when produced continuously rather than manually, a demonstration can be arranged.