SaaS Product Audit Checklist

Use this checklist to review whether your SaaS product’s architecture and critical boundaries still match how the product works today. It is a scoping tool for a technical review, not a generic cybersecurity compliance list.

1. Architecture and trust boundaries

• Map the application, APIs, workers, storage, identity provider, and third-party services in critical workflows.
• Identify where a user, service, webhook, or administrator becomes trusted, and what validates that trust.
• Trace data through paths that create, approve, export, or delete sensitive records.
• Note shared databases, queues, caches, and configuration that can affect more than one tenant or workflow.

Many access and data problems originate in an unstated boundary, not a missing UI permission.

2. Identity and authentication context

• List login methods, session types, API credentials, service identities, and support access paths.
• Check how account switching, impersonation, password resets, invitations, and privileged sign-in flows change the active identity.
• Confirm that downstream services and background work receive only the identity context they need.

The important question is whether the product knows who is acting at every sensitive boundary.

3. Authorization

For each sensitive workflow, identify the actor, target object, required permission, and enforcement point.

• Check object-level reads, updates, deletes, approvals, and downloads from the backend, not only from the interface.
• Test role changes and downgraded permissions against hidden routes, direct API calls, and background actions.
• Review ownership rules, delegated administration, support tooling, and emergency access separately.
• Ask whether a policy is centralized or duplicated across controllers, services, queries, and clients.

For a deeper treatment, see authorization testing for SaaS.

4. Tenant isolation

Document the tenant model before testing it: tenant scope may come from a hostname, membership, database, schema, row filter, claim, or a combination.

• Follow the tenant identifier through requests, database queries, raw queries, caches, file storage, queues, and scheduled work.
• Review list, search, export, and reporting paths; these often aggregate more data than a single-object view.
• Test administration and support workflows that legitimately cross tenants, because they need explicit controls and evidence.
• Check whether retries, asynchronous jobs, and reused connections can lose or reuse the wrong tenant context.

See tenant isolation testing for SaaS when tenant boundaries are the primary concern.

5. APIs and sensitive workflows

• Inventory sensitive reads and writes, including internal APIs that carry the same authority as public ones.
• Review request inputs, object references, pagination, filters, bulk actions, exports, and error handling.
• Trace billing changes, role assignment, data export, approval, deletion, and API-key management from start to finish.
• Check whether workflow state can be skipped, replayed, or performed by the wrong role.

6. Integrations and shared infrastructure

• Identify webhooks, automation platforms, data warehouses, email providers, file services, and support tools that receive customer data or authority.
• Verify credential scope, callback validation, retry behavior, and failure handling.
• Check shared caches, workers, and storage keys for tenant and authorization context.
• Record configuration that can widen access, such as feature flags, environment variables, or deployment roles.

7. Auditability and logging

• For sensitive actions, record the actor, tenant, target object, action, time, and authorization outcome where relevant.
• Include admin/support activity, role changes, exports, API-credential changes, and system-initiated work.
• Preserve enough correlation context to follow a workflow across services.
• Separate audit evidence from ordinary operational logs, which may help debugging but not prove a security decision.

The SaaS audit logging guide explains the evidence questions in more detail.

8. Operational assumptions and technical debt

• Which critical rules rely on developer convention rather than an enforceable boundary?
• Which workflows are hard to test because responsibility is spread across systems?
• Where do special cases, stale permissions, manual fixes, or undocumented runbooks change the risk?
• What should be simplified or made explicit before the next major product change?

Use the checklist to define the right review

Prioritize the workflows with the most sensitive data, highest authority, or widest customer impact. That turns this list into a meaningful scope rather than an exhaustive exercise.

Use this checklist as the starting scope for a SaaS Product Audit. If you already know the risk is a specific access-control or tenant-boundary issue, a SaaS Security Audit may be the more direct engagement. For the information to prepare, see how to prepare for a SaaS product audit.