Build a test account matrix for a SaaS review

A test account matrix connects identities to expected permissions. It tells a reviewer what a member, administrator, invited user, or removed user should be able to do. Without it, an unexpected response can look like a defect when it is intended behavior, or appear normal when it exposes another customer's data.

For a multi-tenant application, include both role and tenant. Two administrator accounts in the same tenant do not test cross-customer isolation. This suggested matrix applies the principle of explicit permission checks described in the OWASP authorization guidance.

Which accounts answer the review question?

These are example expectations, not universal SaaS rules. Replace them with the application's actual policy. If your product allows cross-organization collaboration, represent that relationship explicitly rather than weakening every tenant check.

What should you record without recording secrets?

Save the account label, role, tenant, relevant feature flags, and lifecycle state. Keep credentials in the agreed secret-transfer system. Do not place passwords or session tokens in the matrix, issue tracker, or report.

Include the account's authentication method when it changes behavior. An SSO user and a password user may reach different onboarding or recovery paths. Add these variants only when they are relevant to the scope. A large collection of accounts is not a substitute for a clear expected result.

Document whether role changes take effect immediately or after a defined session refresh. A reviewer cannot evaluate a stale permission result without knowing the intended revocation behavior.

How do you use the matrix during a retest?

Reference the identity label in each test record. Record the object owner and action beside it. This makes it possible to distinguish role escalation from tenant crossover.

Reset the account after any permission change. Verify its effective role through the application or trusted administrative record before the next test. Reuse the same logical labels on a new build, but issue fresh credentials when required.

The matrix is complete when each important deny case has a matching legitimate allow case. A repair that blocks everyone is not a successful authorization fix. Discuss your SaaS access model with Sourced before sharing test credentials.